﻿<!--suppress HtmlUnknownTag -->
<html>

<head>
    <meta http-equiv=Content-Type content="text/html; charset=utf-8">
    <link rel="stylesheet" type="text/css" href="style.css">

</head>

<body>

<div class=document>

    <p class=NemTitle style='margin-bottom:88.0pt;'><img src="image002.png"></p>

    <p class=NemTitleText>NEM NIS API Documentation</p>

    <p class=NemSubtitle>Version 1.20</p>

    <p class=NemSubtitle>
        <time>FILLED AUTOMATICALLY</time>
    </p>
    <p style='page-break-before:always'></p>

    <p class=NemTocHeading>Contents</p>

    <div id="toc">FILLED AUTOMATICALLY

        NOTES:

        use samp+pre for OUTPUTS (nis answers)
        use code+pre for INPUTS (requests

    </div>

    <hr/>
    <div>
        <h4>Changes since 1.19</h4>
        <ul>
            <li>Fixed descriptions of namespace and mosaic transactions. Message payload size.
        </ul>
        <h4>Changes since 1.18</h4>
        <ul>
            <li>Updated the fee table.</li>
        </ul>
        <h4>Changes since 1.17</h4>
        <ul>
            <li>Corrected the API paths for the namespace and mosaic requests in several places.</li>
        </ul>
        <h4>Changes since 1.16</h4>
        <ul>
            <li>Added JSON structures for <a href="#mosaic">Mosaic</a>, <a href="#mosaicDefinition">MosaicDefinition</a>,
                <a href="#mosaicDefinitionMetaDataPair">MosaicDefinitionMetaDataPair</a>, <a href="#mosaicProperties">MosaicProperties</a>,
                <a href="#mosaicLevy">MosaicLevy</a>, <a href="#mosaicId">MosaicId</a>, <a href="#namespace">Namespace</a> and
                <a href="#namespaceMetaDataPair">NamespaceMetaDataPair</a>.
            </li>
            <li>Added or updated JSON structures for <a href="#mosaicDefinitionCreationTransaction">MosaicDefinitionCreationTransaction</a>,
                <a href="#mosaicSupplyChangeTransaction">MosaicSupplyChangeTransaction</a>, <a href="#provisionNamespaceTransaction">ProvisionNamespaceTransaction</a>
                and
                <a href="#transferTransaction">TransferTransaction</a></li>
            <li>Added chapters <a href="#namespaces">Namespaces</a> and <a href="#mosaics">Mosiacs</a> to introduce the concept of NEM namespaces and mosaics.
            </li>
            <li>Added chapters <a href="#provisioning-a-namespace">Provisioning a namespace</a> and <a href="#creating-mosaics">Creating mosaics</a>.</li>
            <li>Updated chapter <a href="#initiating-a-transfer-transaction">Initiating a transfer transaction</a>.</li>
            <li>Added chapters <a href="#retrieving-namespaces-that-a-account-owns">Retrieving namespaces that an account owns</a>,
                <a href="#retrieving-mosaic-definitions-that-an-account-has-created">Retrieving mosaic definitions that an account has created</a> and
                <a href="#retrieving-mosaics-that-an-account-owns">Retrieving mosaics that an account owns</a></li>
            <li>Added chapters <a href="#retrieving-root-namespaces">Retrieving root namespaces</a>,
                <a href="#retrieving-a-specific-namespace">Retrieving a specific namespace</a> and
                <a href="#retrieving-mosaic-definitions">Retrieving mosaic definitions</a></li>
            <li>Updated chapter <a href="#gathering-data-for-the-signature">Gathering data for the signature</a> by adding the
                <a href="#transferTransaction">TransferTransaction</a> version 2 fields and adding the new transactions
                <a href="#provisionNamespaceTransaction">ProvisionNamespaceTransaction</a>,
                <a href="#mosaicDefinitionCreationTransaction">MosaicDefinitionCreationTransaction</a> and
                <a href="#mosaicSupplyChangeTransaction">MosaicSupplyChangeTransaction</a>.
            </li>
            <li>Added new validation failure messages for namespace and mosaic validation</li>
        </ul>

        <h4>Changes since 1.15</h4>
        <ul>
            <li>updated chapter 6.8 to reflect correct fee calculation for aggregate modification transactions.</li>
        </ul>

        <h4>Changes since 1.14</h4>
        <ul>
            <li>updated chapter 6.3, 6.5 and appendix A 8.19.2 to reflect that aggregate modification transactions need to have version 2.</li>
        </ul>

        <h4>Changes since 1.13</h4>
        <ul>
            <li>added chapter 3.1.10 <a href="#retrieving-the-unlock-info"> Retrieving the unlock info</a></li>
        </ul>

        <h4>Changes since 1.12</h4>
        <ul>
            <li>updated chapter 6.3 - 6.5 to reflect the m of n multisig account changes</li>
            <li>updated chapter 6.7.1 to reflect the m of n multisig account changes</li>
            <li>updated structure <a href="#multisigAggregateModificationTransaction">MultisigAggregateModificationTransaction</a></li>
            <li>replaced table tag with fields tag</li>
            <li>updated structures that have changed</li>
            <li>added missing error messages</li>
        </ul>
        <h4>Changes since 1.11</h4>
        <ul>
            <li>updated chapter 3.1.2 <a href="#requesting-the-account-data"> Requesting the account data</a></li>
            <li>added chapter 3.1.3 <a href="#requesting-the-original-account-data-for-a-delegate-account"> Requesting the original account data for a delegate
                account</a></li>
            <li>updated structure <a href="#accountInfo">AccountInfo</a></li>
        </ul>

        <h4>Changes since 1.10</h4>
        <ul>
            <li>added chapter 3.2 <a href="#retrieving-historical-account-data"> Retrieving historical account data</a></li>
            <li>added structure <a href="#accountHistoricalDataViewModel">AccountHistoricalDataViewModel</a></li>
        </ul>

        <h4>Changes since 1.9</h4>
        <ul>
            <li>corrected the fee formula for aggregate modification transactions in the fee table</li>
        </ul>

        <h4>Changes since 1.8</h4>
        <ul>
            <li>updated document to reflect the possible versions (main and test network) of the block and transactions structures</li>
            <li>updated structure <a href="#node">Node</a></li>
        </ul>

        <h4>Changes since 1.7</h4>
        <ul>
            <li>added chapter 6.7 <a href="#creating-a-signed-transaction"> Creating a signed transaction</a> and added structure <a href="#requestAnnounce">RequestAnnounce</a>
            </li>
            <li>updated structures <a href="#transactionMetaData">TransactionMetaData</a>, <a href="#nemAnnounceResult">NemAnnounceResult</a></li>
        </ul>

        <h4>Changes since 1.6</h4>
        <ul>
            <li>added table with <a href="#transaction-fees">transaction fees</a></li>
            <li>fixed description of <a href="#requestPrepareAnnounce">RequestPrepareAnnounce</a></li>
        </ul>

        <h4>Changes since 1.5</h4>
        <ul>
            <li>added <a href="#generating-new-account-data">Generating new account data</a></li>
            <li>updated <a href="#requesting-the-account-data">Requesting the account data</a></li>
            <li>updated structures <a href="#keyPairViewModel">KeyPairViewModel</a>, <a href="#accountMetaData">AccountMetaData</a></li>
        </ul>
    </div>
    <hr/>

    <h1>Introduction</h1>

    <h2>General Information</h2>

    <p>The NEM Infrastructure Server (short: NIS) was written in Java. It needs Java 8 to run. It can run with at least 512MB memory for the java virtual
        machine but we recommend at least 1GB.</p>

    <h2>Installation</h2>

    <p>NIS can be installed either via installer using the URL <a href="http://bob.nem.ninja/installer/">NEM Infrastructure Server</a> or as stand-alone package
        which is hosted on <a href="http://bob.nem.ninja/">http://bob.nem.ninja/</a>. The installer only supports 64 bit versions of Java. The current
        stand-alone version as of this writing is <a href="http://bob.nem.ninja/nis-ncc-0.5.13.tgz">nis-ncc-0.5.13.tgz</a>. When using the installer both
        installation and the start-up of the software is automatic. The stand-alone version needs to be unzipped to a directory of your choice. It is then
        started by running runNis.bat (windows) or nix.runNis.sh (linux) from the command prompt.</p>

    <h2>Requests</h2>

    <p>NIS uses port 7890 to communicate with its clients. It accepts both HTTP GET and POST requests.</p>

    <p>Assuming that the NIS is running locally, HTTP GET requests can be executed from a browser and have the form:</p>

    <p><a href="http://127.0.0.1:7890/">http://127.0.0.1:7890</a>&lt;path to API request&gt;?&lt;parameters&gt; for example:</p>

    <p><a href="http://127.0.0.1:7890/account/get?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS">http://127.0.0.1:7890/account/get?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS</a>
    </p>

    <p>HTTP POST request usually cannot be executed from within the browser unless you use a plugin which is able to do it. HTTP POST requests use JSON
        structures in the request body to supply data to NIS.</p>

    <p>Both request types return (if any data is returned) data using JSON structures. <a href="#appendix-A:-description-of-the-JSON-structures">Appendix A:
        Description of the JSON Structures</a> explains all JSON structures used in this document.</p>

    <h1>NIS status related requests</h1>

    <p>There are two requests by which you can get information about the status of NIS. The /heartbeat request gives you information if the node is up and
        responsive. The /status request gives more detailed information about the state of NIS. Both requests return a NemRequestResult object. See
        <appa>NemRequestResult</appa>
        for more details on the interpretation of a NemRequestResult.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Heart beat request</h2>
    <api get>/heartbeat</api>

    <desc>
        <p class=NemNoSpacing>Determines if NIS is up and responsive.</p>
    </desc>

    <h4>No Parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/heartbeat">http://127.0.0.1:7890/heartbeat</a></p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
    "code": 1,
    "type": 2,
    "message": "ok"
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If there is no response to this request,
        NIS is either not running or is in a state where it can't serve requests.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Status Request</h2>
    <api get>/status</api>

    <desc>
        <p class=NemNoSpacing>Determines the status of NIS.</p>
    </desc>

    <h4>No Parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/status">http://127.0.0.1:7890/status</a></p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{ 
    "code": 6, 
    "type": 4, 
    <b>"message": "status"</b>
} 
    </resp>

    <p class=NemNoSpacing>The code can be interpreted as follows:</p>
    <vals>
        0: Unknown status.
        1: NIS is stopped.
        2: NIS is starting.
        3: NIS is running.
        4: NIS is booting the local node (implies NIS is running).
        5: The local node is booted (implies NIS is running).
        6: The local node is synchronized (implies NIS is running and the local node is booted).
        7: NIS local node does not see any remote NIS node (implies running and booted).
        8: NIS is currently loading the block chain from the database. In this state NIS cannot serve any requests.
    </vals>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If there is no response to this request,
        NIS is either not running or is in a state where it can't serve requests.</p>

    <h1>Account related requests</h1>

    <p>This chapter will guide you through the
        process of retrieving account information from a NEM Infrastructure Server. The
        information that can be retrieved is the durable account data, its meta data
        and information about transactions and harvested blocks.</p>

    <p>NIS supports two different kind of accounts: normal accounts and multsig (short for: multi signature) accounts:</p>

    <h4>Normal accounts:</h4>

    <p>Normal accounts are created and controlled
        by a private key. Any action for the account like sending NEM to another
        account via a transfer transaction is signed with this private key. If an
        attacker gains knowledge of the private key, he/she can rob the account. The
        private key must therefore be kept secret by all means.</p>

    <h4>Multisig accounts:</h4>

    <p>Multisig accounts can be created by
        converting a normal account to a multisig account via a <b>aggregate
            modification transaction</b>. This adds cosignatories to the account. After that
        modification, only the cosignatories can initiate an action for the account.
        Any action must be signed by all cosignatories. This makes a multisig account
        significantly more secure than a normal account. When a single cosignatory
        private key is gained by an attacker, the attacker still can't initiate any
        action on the account since <b>all</b> cosignatories must sign. It is strongly
        recommended to convert any account holding a significantly high amount of NEM
        into a multisig account with at least 3 cosignatories. Once converted to a
        multisig account, the original private key for the account plays no role any
        more.</p>

    <p>Durable data is either stored in the
        database or can be calculated from other database data. The corresponding JSON
        object is described in
        <appa>AccountInfo</appa>
        . It has the fields:
    </p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p>Each account has a unique address. First letter of an address indicate
                    the network the account belongs to. Currently two networks are defined: the
                    test network whose account addresses start with a capital <b>T</b> and the main
                    network whose account addresses always start with a capital <b>N</b>. Addresses have
                    always a length of 40 characters and are <a href="http://en.wikipedia.org/wiki/Base32">base-32</a> encoded.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>balance</p>
            </td>
            <td>
                <p>Each account has a balance which is an integer greater or equal to
                    zero and denotes the number of <b>micro</b> NEMs which the account owns. Thus a
                    balance of 123456789 means the account owns 123.456789 NEM. A balance is
                    split into its vested and unvested part. Only the vested part is relevant for
                    the importance calculation. For transfers from one account to another only
                    the balance itself is relevant.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>importance</p>
            </td>
            <td>
                <p>Each account is assigned an importance. The importance is a
                    decimal number between 0 and 1. It denotes the probability of an account to
                    harvest the next block in case the account has harvesting turned on and all
                    other accounts are harvesting too. The exact formula for calculating the
                    importance is not public yet. Accounts need at least 10k <b>vested</b> NEM to be
                    included in the importance calculation.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>publicKey</p>
            </td>
            <td>
                <p>The public key of an account can be used
                    to verify signatures of the account. Only accounts that have already
                    published a transaction have a public key assigned to the account. Otherwise
                    the field is null.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>label</p>
            </td>
            <td>
                <p>This field is not used yet and is always null.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>harvestedBlocks</p>
            </td>
            <td>
                <p>Harvesting is the process of generating new blocks. The field
                    denotes the number of blocks that the account harvested so far. For a new
                    account the number is 0.</p>
            </td>
        </tr>
    </table>


    <p>The meta data for an account describes the
        harvesting status of an account, and in case that the account is a cosignatory
        of at least one multisig account, the list of those multisig accounts. An
        account can either harvest with its current importance or delegate the
        harvesting to a so called remote account. In the latter case the remote account
        uses the importance of the original account to harvest. The corresponding JSON
        object and the possible values for the status/remoteStatus are described in
        <appa>AccountMetaDataPair</appa>
        . The meta
        data consists of the following fields:
    </p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>status</p>
            </td>
            <td>
                <p>This field describes the harvesting status of an account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>remoteStatus</p>
            </td>
            <td>
                <p>The field describes the status of remote harvesting.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>cosignatoryOf</p>
            </td>
            <td>
                <p>Array of AccountInfo structures that describe the multisig
                    accounts that this account is cosignatory of.</p>
            </td>
        </tr>
    </table>


    <p>Known accounts have at least one incoming
        transaction. The corresponding JSON objects are described in
        <appa>Transaction</appa>
        ,
        <alnk>TransactionMetaData</alnk>
        and
        <alnk>TransactionMetaDataPair</alnk>
        .
    </p>

    <p>A transaction has always the following fields:</p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>timeStamp</p>
            </td>
            <td>
                <p>The number of seconds elapsed since the creation of the nemesis
                    block. Future timestamps are not allowed. Transaction validation detects
                    future timestamps and returns an error in that case. Network time
                    synchronization ensures that any NEM software component will use valid timestamps
                    when creating transactions.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>signature</p>
            </td>
            <td>
                <p>The transaction signature. The transaction signature is validated
                    using the supplied public key in the field signer. If the signature is not
                    valid, an error is returned from validation.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>fee</p>
            </td>
            <td>
                <p>The fee for the transaction. The higher the fee, the higher is the
                    priority of the transaction. Transactions with high priority get included in
                    a block before transactions with lower priority. If the sender does not have
                    enough funds the validation will result in an error</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>type</p>
            </td>
            <td>
                <p>The transaction type. Currently the following types of
                    transactions are supported:</p>
                <vals>
                    0x101: Transfer of NEM from sender to recipient.
                    0x801: Transfer of importance from sender to remote account.
                    0x1001: An aggregate modification transaction, which converts a normal account into a multisig account.
                    0x1002: A multisig signature transaction which is used to sign a multisig transaction.
                    0x1003: A multisig transaction, which is used for multisig accounts.
                </vals>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>deadline</p>
            </td>
            <td>
                <p>The deadline of the transaction. The deadline is given as the
                    number of seconds elapsed since the creation of the nemesis block. If a
                    transaction does not get included in a block before the deadline is reached,
                    it is deleted.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>version</p>
            </td>
            <td>
                <p>The version of the structure. The following version are currently support.</p>
                <li>0x68 &lt;&lt; 24 + 1 (1744830465 as 4 byte integer): the main network version</li>
                <li>0x60 &lt;&lt; 24 + 1 (1610612737 as 4 byte integer): the mijin network version</li>
                <li>0x98 &lt;&lt; 24 + 1 (-1744830463 as 4 byte integer): the test network version</li>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>signer</p>
            </td>
            <td>
                <p>The public key of the account that created the transaction. The
                    public key is encoded as hexadecimal string.</p>
            </td>
        </tr>
    </table>

    <p>Depending on the type of the transaction, there are additional fields which are specific to given type.
        For instance a transfer transaction will have the additional fields.</p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>recipient</p>
            </td>
            <td>
                <p>The address of the recipient. If the address is not valid an error
                    is returned from validation.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>message</p>
            </td>
            <td>
                <p>Optionally a transfer transaction can contain a message.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>payload</p>
            </td>
            <td>
                <p>Optional field in case the transaction contains a message. The
                    payload is the actual (possibly encrypted) message data. The payload is
                    allowed to have a maximal size of 1024 bytes. Transaction validation detects
                    if the limit is exceeded and returns an error in this case.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>type</p>
            </td>
            <td>
                <p>Optional field in case the transaction contains a message. The
                    field holds the message type information. Possible message types are:</p>
                <vals>
                    1: The message is not encrypted.
                    2: The message is encrypted.
                </vals>
            </td>
        </tr>
    </table>

    <p>Please refer to <a href="#appendix-A:-description-of-the-JSON-structures">Appendix A</a> for detailed information on the various transactions types and
        their additional fields.</p>

    <p>Transaction meta data contains only following field:</p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>height</p>
            </td>
            <td>
                <p>The height of the block in which the transaction was included.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>id</p>
            </td>
            <td>
                <p>The id of the transaction.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>hash</p>
            </td>
            <td>
                <p>The hash of the transaction.</p>
            </td>
        </tr>
    </table>

    <p></p>

    <p>Accounts can harvest (i.e. generate new)
        blocks if they are lucky. The account which harvests a block collects the fees
        which are included in the transactions in the block. The information which
        blocks were harvested by an account can be requested. The request returns an
        array of HarvestInfo JSON objects. For an example see
        <appa>HarvestInfo</appa>
    </p>

    <p>A harvest info object has the following fields:</p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>timeStamp</p>
            </td>
            <td>
                <p>The number of seconds elapsed since the creation of the nemesis block.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>id</p>
            </td>
            <td>
                <p>The database id for the block.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>difficulty</p>
            </td>
            <td>
                <p>The block difficulty.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>totalFee</p>
            </td>
            <td>
                <p>The total fee collected by harvesting the block.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>height</p>
            </td>
            <td>
                <p>The height of the harvested block.</p>
            </td>
        </tr>
    </table>

    <p></p>

    <p>It is possible to request an array with the
        importance information for all accounts. The request returns an array of
        AccountImportanceViewModel JSON objects. For an example see
        <appa>AccountImportanceViewModel</appa>
        .
    </p>

    <p>An account importance view model has the following fields:</p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p>The address of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>importance</p>
            </td>
            <td>
                <p>Substructure that describes the importance of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>isSet</p>
            </td>
            <td>
                <p>Indicates if the fields &quot;score&quot;, &quot;ev&quot; and &quot;height&quot; are available.</p>

                <p>isSet can have the values 0 or 1. In case isSet is 0 the following fields are not available.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>score</p>
            </td>
            <td>
                <p>The importance of the account. The importance ranges between 0 and 1.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>ev</p>
            </td>
            <td>
                <p>The page rank portion of the importance. The page rank ranges between 0 and 1.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>height</p>
            </td>
            <td>
                <p>The height at which the importance calculation was performed.</p>
            </td>
        </tr>
    </table>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Retrieving account data</h2>

    <h3>Generating new account data</h3>
    <api get>/account/generate</api>

    <desc>
        <p class=NemNoSpacing>Generates a <a href="#keyPairViewModel">KeyPairViewModel</a>.</p>
    </desc>

    <h4>No Parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/generate">http://127.0.0.1:7890/account/generate</a></p>

    <h4>Example of returned JSON object:</h4>

    <resp>

{
    "privateKey": "0962c6505d02123c40e858ff8ef21e2b7b5466be12c4770e3bf557aae828390f",
    "address": "NCKMNCU3STBWBR7E3XD2LR7WSIXF5IVJIDBHBZQT",
    "publicKey": "c2e19751291d01140e62ece9ee3923120766c6302e1099b04014fe1009bc89d3"
}

    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Requesting the account data</h3>
    <api get>/account/get</api>

    <desc>
        <p class=NemNoSpacing>Gets an <a href="#accountMetaDataPair">AccountMetaDataPair</a> for an account.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/get?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS">http://127.0.0.1:7890/account/get?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
    "account":
    {
        "address": "TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS",
        "balance": 124446551689680,
        "vestedBalance": 104443451691625,
        "importance": 0.010263666447108395,
        "publicKey": "a11a1a6c17a24252e674d151713cdf51991ad101751e4af02a20c61b59f1fe1a",
        "label": null,
        "harvestedBlocks": 645
    },
    "meta":
    {
        "cosignatoryOf": [ ],
        "cosignatories": [ ],
        "status": "LOCKED",
        "remoteStatus": "ACTIVE"
    }
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address parameter is not valid, NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <p></p>

    <p>Alternatively you can retrieve the account data by providing the public key for the account:</p>

    <api get>/account/get/from-public-key</api>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>publicKey</p>
            </td>
            <td>
                <p class=NemNoSpacing>The public key of the account as hex string.</p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/get/from-public-key?publicKey=f9bd190dd0c364261f5c8a74870cc7f7374e631352293c62ecc437657e5de2cd">http://127.0.0.1:7890/account/get/from-public-key?publicKey=f9bd190dd0c364261f5c8a74870cc7f7374e631352293c62ecc437657e5de2cd</a>
    </p>

    <p>The returned JSON object has the same structure as in the first example.</p>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the public key parameter is not valid, NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <h3>Requesting the original account data for a delegate account</h3>
    <api get>/account/get/forwarded</api>

    <desc>
        <p class=NemNoSpacing>Given a delegate (formerly known as remote) account's address, gets the <a href="#accountMetaDataPair">AccountMetaDataPair</a>
            for the account for which the given account is the delegate account. If the given account address is not a delegate account for any account, the
            request returns the <a href="#accountMetaDataPair">AccountMetaDataPair</a> for the given address.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the delegate account.</p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/get/forwarded?address=NC2ZQKEFQIL3JZEOB2OZPWXWPOR6LKYHIROCR7PK">http://127.0.0.1:7890/account/get/forwarded?address=NC2ZQKEFQIL3JZEOB2OZPWXWPOR6LKYHIROCR7PK</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
    "account":
    {
        "address": "NALICE2A73DLYTP4365GNFCURAUP3XVBFO7YNYOW",
        "balance": 11793338398661,
        "vestedBalance": 10890953464862,
        "importance": 0.001264596432148395,
        "publicKey": "bdd8dd702acb3d88daf188be8d6d9c54b3a29a32561a068b25d2261b2b2b7f02",
        "label": null,
        "harvestedBlocks": 742
    },
    "meta":
    {
        "cosignatoryOf": [ ],
        "cosignatories": [ ],
        "status": "LOCKED",
        "remoteStatus": "ACTIVE"
    }
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address parameter is not valid, NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <p></p>

    <p>Alternatively you can retrieve the original account data by providing the public key of the delegate account:</p>

    <api get>/account/get/forwarded/from-public-key</api>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>publicKey</p>
            </td>
            <td>
                <p class=NemNoSpacing>The public key of the account as hex string.</p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/get/forwarded/from-public-key?publicKey=bdd8dd702acb3d88daf188be8d6d9c54b3a29a32561a068b25d2261b2b2b7f02">http://127.0.0.1:7890/account/get/forwarded/from-public-key?publicKey=bdd8dd702acb3d88daf188be8d6d9c54b3a29a32561a068b25d2261b2b2b7f02</a>
    </p>

    <p>The returned JSON object has the same structure as in the first example.</p>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the public key parameter is not valid, NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Requesting the account status</h3>
    <api get>/account/status</api>

    <desc>
        <p class=NemNoSpacing>Gets the <a href="#accountMetaData">AccountMetaData</a> from an account.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>Address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/status?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS">http://127.0.0.1:7890/account/status?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
    "cosignatoryOf": [ ],
    "status": "LOCKED",
    "remoteStatus": "ACTIVE"
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address parameter is not valid,
        NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <h3>Requesting transaction data for an account</h3>

    <p>A transaction is said to be incoming with
        respect to an account if the account is the recipient of the transaction. In
        the same way outgoing transaction are the transactions where the account is the
        sender of the transaction. Unconfirmed transactions are those transactions that
        have not yet been included in a block. Unconfirmed transactions are <b>not</b>
        guaranteed to be included in any block.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h4>Incoming transactions</h4>
    <api get>/account/transfers/incoming</api>
    <desc>
        <p class=NemNoSpacing>Gets an array of <a href="#transactionMetaDataPair">TransactionMetaDataPair</a> objects
            where the recipient has the address given as parameter to the request. A
            maximum of 25 transaction meta data pairs is returned. The returned transaction
            meta data pairs are sorted in descending order in which they were written to
            the database.</p>

        <p class=NemNoSpacing> The second parameter is optional. When it's not present, the
            request will return newest transactions according to the above criteria. When hash
            is supplied as second parameter, the request will return up to 25 transactions
            that appeared directly before the transaction that has the supplied hash sorted
            according to the above criteria.</p>

        <p class=NemNoSpacing>The third parameter is optional. When an
            id is supplied as third parameter, the request will return up to 25
            transactions that appeared directly before the transaction that has the
            supplied id sorted according to the above criteria.</p>

        <p class=NemNoSpacing>If less than 25 transactions fulfill the
            requirements, only those transactions are returned.</p>

        <p class=NemNoSpacing></p>
    </desc>

    <h4>Parameters:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p></td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>hash</p>
            </td>
            <td>
                <p class=NemNoSpacing>The 256 bit sha3 hash of the
                    transaction up to which transactions are returned.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>id </p>
            </td>
            <td>
                <p class=NemNoSpacing>The transaction id up to which
                    transactions are returned.</p>
            </td>
        </tr>
    </table>

    <h4></h4>

    <h4>Example:</h4>

    <p>
        <a href="http://127.0.0.1:7890/account/transfers/incoming?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&amp;hash=949583a20ebdfdcb58277eb42fef3e66e9e6bbfc47304d8741a82c68f7c53a2">http://127.0.0.1:7890/account/transfers/incoming?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&amp;hash=949583a20ebdfdcb58277eb42fef3e66e9e6bbfc47304d8741a82c68f7c53a2</a>
    </p>

    <h4>Example of returned JSON object (test network):</h4>

    <resp>
{
       "data": [
       {
              "meta":
              {
                     "id": 71245,
                     "height": 40706,
                     "hash": {
                         "data":"15c373ad4c3fe6af47d1941379ff262f785bdcfa07c02ac3608bc10da27d5e82"
                     }
              },
              "transaction":
              {
                     "timeStamp": 9106400,
                     "amount": 1000000000,
                     "signature": "449cd76ea8bda2220b3d6ad6f8db5f81d4e68ad3d4b0c3db9a3c267355657639eabed3dbcef8e0cc22953ae2b36a22ee7dc6327484c9649cccd686a511eca105",
                     "fee": 3000000,
                     "recipient": "TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS",
                     "type": 257,
                     "deadline": 9149600,
                     "message":
                     {
                           "payload": "280000005444334b32493543524850595634425a5a5a4c335850454e4",
                           "type": 2
                     },
                     "version": -1744830463,
                     "signer": "c20a1dffe699c7a68328986273265e33fceebe074f274240ef890dd80ad55ed6"
              }
       },
       {
              "meta":
              {
                     "id": 71356,
                     "height": 40629,
                     "hash": {
                         "data":"37c34ead4c3fe6af42d994135798262f785ba2d807c02ac3608bc10da12e5f87"
                     }
              },
              "transaction":
              {
                     "timeStamp": 9101541,
                     "amount": 49997995000000,
                     "signature": "57c3c48d2ae8b24240b57d72493f498cfeb61e2ab87237dc0e08c51007d5c7f15847d0e08c0286e68a72028925db5fa809ca9d57e2cb6eebe11822176a834c0b",
                     "fee": 2005000000,
                     "recipient": "TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS",
                     "type": 257,
                     "deadline": 9144741,
                     "message":
                     {
                           "payload": "526f6262657279212121",
                           "type": 1
                     },
                     "version": -1744830463,
                     "signer": "546e4fb9c81db84e04d8e9e67380db0fe1f540df09a527fb995b589b5695ae24"
              }
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address parameter is not valid or
        the id cannot be found in the database, NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h4>Outgoing transactions</h4>
    <api get>/account/transfers/outgoing</api>

    <desc>
        <p class=NemNoSpacing>Gets an array of transaction meta data
            pairs where the recipient has the address given as parameter to the request. A
            maximum of 25 transaction meta data pairs is returned. For details about
            sorting and discussion of the second parameter see <a href="#incoming-transactions">Incoming transactions</a>.</p>
    </desc>
    <h4>Parameters:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>hash</p>
            </td>
            <td>
                <p class=NemNoSpacing>The 256 bit sha3 hash of the
                    transaction up to which transactions are returned.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>id </p>
            </td>
            <td>
                <p class=NemNoSpacing>The transaction id up to which
                    transactions are returned.</p>
            </td>
        </tr>
    </table>

    <h4></h4>

    <h4>Example:</h4>

    <p class=NemNoSpacing><a
            href="http://127.0.0.1:7890/account/transfers/outgoing?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&amp;hash=949583a20ebdfdcb58277eb42fef3e66e9e6bbfc47304d8741a82c68f7c53a22">http://127.0.0.1:7890/account/transfers/outgoing?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&amp;hash=949583a20ebdfdcb58277eb42fef3e66e9e6bbfc47304d8741a82c68f7c53a22</a>
    </p>

    <h4>Example of returned JSON object (test network):</h4>

    <resp>
{
       "data": [
       {
              "meta":
              {
                     "id": 70498,
                     "height": 40803,
                     "hash": {
                         "data":"37c34ead4c3fe6af42d994135798262f785ba2d807c02ac3608bc10da12e5f87"
                     }
              },
              "transaction":
              {
                     "timeStamp": 9111526,
                     "amount": 1000000000,
                     "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
                     "fee": 3000000,
                     "recipient": "TDGIMREMR5NSRFUOMPI5OOHLDATCABNPC5ID2SVA",
                     "type": 257,
                     "deadline": 9154726,
                     "message":
                     {
                           "payload": "74657374207472616e73616374696f6e",
                           "type": 1
                     },
                     "version": -1744830463,
                     "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
              }
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address parameter is not valid or
        the id cannot be found in the database, NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h4>All transactions</h4>
    <api get>/account/transfers/all</api>

    <desc>
        <p class=NemNoSpacing>Gets an array of transaction meta data
            pairs for which an account is the sender or receiver. A maximum of 25
            transaction meta data pairs is returned. For details about sorting and
            discussion of the second parameter see <a href="#incoming-transactions">Incoming transactions</a>.</p>
    </desc>

    <h4>Parameters:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>hash</p>
            </td>
            <td>
                <p class=NemNoSpacing>The 256 bit sha3 hash of the
                    transaction up to which transactions are returned.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>id </p>
            </td>
            <td>
                <p class=NemNoSpacing>The transaction id up to which
                    transactions are returned.</p>
            </td>
        </tr>
    </table>

    <h4></h4>

    <h4>Example:</h4>

    <p>
        <a href="http://127.0.0.1:7890/account/transfers/all?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&amp;hash=949583a20ebdfdcb58277eb42fef3e66e9e6bbfc47304d8741a82c68f7c53a22">http://127.0.0.1:7890/account/transfers/all?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&amp;hash=949583a20ebdfdcb58277eb42fef3e66e9e6bbfc47304d8741a82c68f7c53a22</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <p class=NemNoSpacing>See example for <a href="#incoming-transactions">Incoming transactions</a> or <a href="#outgoing-transactions">Outgoing
        transactions</a>.</p>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address parameter is not valid or
        the id cannot be found in the database, NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h4>Unconfirmed transactions</h4>

    <api get>/account/unconfirmedTransactions</api>


    <desc>
        <p class=NemNoSpacing>Gets the array of transactions for which
            an account is the sender or receiver and which have not yet been included in a
            block. The returned structure is UnconfirmedTransactionMetaDataPair see
            <appa>UnconfirmedTransactionMetaDataPair</appa>
        </p>
    </desc>

    <h4>Parameters:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/unconfirmedTransactions?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS">http://127.0.0.1:7890/account/unconfirmedTransactions?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS</a>
    </p>

    <h4>Example of returned JSON object (test network):</h4>

    <resp>
{
       "meta": {
           "data": "d7c9e33421e43bf4a5d6e21304c8096c599142755d581bd6e9037f41545a5873"
       },
       "data": [
       {
              "timeStamp": 9131839,
              "amount": 1000000000,
              "signature": "0acface77696a54340a7da8592750ea0410f62717d07e4df30e09718092521262465df5c4d98d32cd9d6e8699d66e016ec8db716d20090ad99cc16f7a6d13904",
              "fee": 2000000,
              "recipient": "TDGIMREMR5NSRFUOMPI5OOHLDATCABNPC5ID2SVA",
              "type": 257,
              "deadline": 9175039,
              "message": {
                     "payload": "",
                     "type": 1
              },
              "version": -1744830463,
              "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address parameter is not valid,
        NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        Errors for details about errors.
    </p>

    <h3>Transaction data with decoded messages</h3>

    <p>All the requests for retrieving transaction data for an account which were described in previous part
        do not decode any message contained in a transaction.
        The following requests are similar to the ones above but are able to return transaction data with decoded messages.
        Decoding requires the private key of an account for which transactions are requested.
        Therefore the following requests <b>should only be done when NIS is running locally</b>.</p>

    <h4>Incoming/outgoing/all transactions with decoded messages</h4>
    <api post>/local/account/transfers/incoming</api>
    <api post>/local/account/transfers/outgoing</api>
    <api post>/local/account/transfers/all</api>

    <desc>
        <p class=NemNoSpacing>The request returns incoming/outgoing/all transactions as described in the previous chapter.
            The only difference is that if a transaction contains an encoded message, this message will be decoded before it is
            sent to the requester.</p>
    </desc>

    <h4>Parameters:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>page</p>
            </td>
            <td>
                <p class=NemNoSpacing>An AccountPrivateKeyTransactionsPage
                    JSON object as described in
                    <appa>AccountPrivateKeyTransactionsPage</appa>
                </p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p>Request cannot be performed in a browser.</p>

    <h4>Example of returned JSON object:</h4>

    <p>See section: <a href="#requesting-transaction-data-for-an-account">Requesting transaction data for an account</a></p>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the private key is not supplied, NIS returns an error.
        See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Requesting harvest info data for an account</h3>

    <api get>/account/harvests</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of harvest info objects
            for an account.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>hash </p>
            </td>
            <td>
                <p class=NemNoSpacing>The 256 bit sha3 hash of the block up to which harvested blocks are returned.</p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p>
        <a href="http://127.0.0.1:7890/account/harvests?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&amp;hash=81d52a7df4abba8bb1613bcc42b6b93cf3114524939035d88ae8e864cd2c34c8">http://127.0.0.1:7890/account/harvests?address=TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&amp;hash=81d52a7df4abba8bb1613bcc42b6b93cf3114524939035d88ae8e864cd2c34c8</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
       "data": [{
              "timeStamp": 8879051,
              "blockHash": {
                     "data": "be3bb308ce33625f0dab64fd31b9ebe1c50dd4b94b43b03c228f481ab82458c3"
              },
              "totalFee": 102585065,
              "height": 37015
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address parameter is not valid or
        the hash cannot be found in the database, NIS returns an error. See
        <alnk>Appendix B: NIS Errors</alnk>
        Errors for details about errors.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Retrieving account importances for accounts</h3>

    <api get>/account/importances</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of account importance view model objects.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/importances">http://127.0.0.1:7890/account/importances</a></p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
       "data": [{
              "address": "TCYGT6GHZPNASMAXV7YCFCU5R5XTJKNNT66R4A4T",
              "importance": {
                     "isSet": 0
              }
       },
       {
              "address": "TD2JJJVPKDZFXWK3N3ZJLN7A5TGNOTM3J5EVSTIG",
              "importance": {
                     "score": 0.001222376902598832,
                     "ev": 0.004252356221747241,
                     "isSet": 1,
                     "height": 40926
              }
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Retrieving namespaces that an account owns</h3>

    <api get>/account/namespace/page</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of namespace objects for a given account address. The parent parameter is optional.
            If supplied, only sub-namespaces of the parent namespace are returned.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>parent</p>
            </td>
            <td>
                <p class=NemNoSpacing>The optional parent namespace id.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>id</p>
            </td>
            <td>
                <p class=NemNoSpacing>The optional namespace database id up to which namespaces are returned.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>pageSize</p>
            </td>
            <td>
                <p class=NemNoSpacing>The (optional) number of namespaces to be returned.</p>
            </td>
        </tr>
    </table>
    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/namespace/page?address=TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH&amp;parent=makoto.metal">http://127.0.0.1:7890/account/namespace/page?address=TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH&amp;parent=makoto.metal</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
        "data": [{
                "fqn": "makoto.metal.coins",
                "owner": TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
                "height": 13465
        }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>NIS returns an error if the address or the parent (if supplied) is invalid.
        See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Retrieving mosaic definitions that an account has created</h3>

    <api get>/account/mosaic/definition/page</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of mosaic definition objects for a given account address. The parent parameter is optional.
            If supplied, only mosaic definitions for the given parent namespace are returned. The id parameter is optional and allows
            retrieving mosaic definitions in batches of 25 mosaic definitions. For more information how to use the id see
            <a href="#incoming-transactions">Incoming transactions</a>.
        </p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>parent</p>
            </td>
            <td>
                <p class=NemNoSpacing>The optional parent namespace id.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>id</p>
            </td>
            <td>
                <p class=NemNoSpacing>The optional mosaic definition database id up to which mosaic definitions are returned.</p>
            </td>
        </tr>
    </table>
    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/mosaic/definition/page?address=TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH&amp;parent=makoto.metal.coins">http://127.0.0.1:7890/account/mosaic/definition/page?address=TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH&amp;parent=makoto.metal.coins</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
        "data": [{
            "creator": "10cfe522fe23c015b8ab24ef6a0c32c5de78eb55b2152ed07b6a092121187100",
            "id": {
                "namespaceId": "makoto.metal.coins",
                "name": "silver coin"
            },
            "description": "Real silver coins, pure silver",
            "properties": [{
                "name": "divisibility",
                "value": "0"
            },{
                "name": "initialSupply",
                "value": "1000"
            },{
                "name": "supplyMutable",
                "value": "false"
            },{
                "name": "transferable",
                "value": "true"
            }]
        }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>NIS returns an error if the address, the parent (if supplied) or the id (if supplied) is invalid.
        See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Retrieving mosaics that an account owns</h3>

    <api get>/account/mosaic/owned</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of mosaic objects for a given account address.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
    </table>
    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/account/mosaic/owned?address=TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH">http://127.0.0.1:7890/account/mosaic/owned?address=TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
        "data": [{
            "mosaicId": {
                "namespaceId": "alice.drinks",
                "name": "orange juice"
            },
            "quantity": 123
        },{
            "mosaicId": {
                "namespaceId": "makoto.metal.coins",
                "name": "silver coin"
            },
            "quantity": 8
        }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>NIS returns an error if the address is invalid.
        See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <h3>Locking and unlocking accounts</h3>

    <p>Accounts that have at least 10000 vested
        NEM balance are allowed to harvest blocks. To do that the account must be
        unlocked. After start-up of NIS all accounts are locked by default.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h4>Unlocking the account (enables harvesting)</h4>

    <api post>/account/unlock</api>


    <desc>
        <p class=NemNoSpacing>Unlocks an account (starts harvesting).</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON><b><span style='color:#C00000'>privateKey</span></b></p>
            </td>
            <td>
                <p class=NemNoSpacing>A PrivateKey JSON object as described in
                    <appa>PrivateKey</appa>
                </p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p class=NemNoSpacing>Request cannot be performed in a browser.</p>

    <h4>No return value</h4>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h4>Locking the account (stops harvesting)</h4>

    <api post>/account/lock</api>


    <desc>
        <p class=NemNoSpacing>Locks an account (stops harvesting).</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON><b><span style='color:#C00000'>privateKey</span></b></p>
            </td>
            <td>
                <p class=NemNoSpacing>A PrivateKey JSON object as described in
                    <appa>PrivateKey</appa>
                </p>
            </td>
        </tr>
    </table>


    <h4>Example:</h4>

    <p class=NemNoSpacing>Request cannot be performed in a browser.</p>

    <h4>No return value</h4>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>Both requests return an error if the
        private key does not correspond to a known account or the account is not
        allowed to harvest. See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <h3>Retrieving the unlock info</h3>

    <p>Each node can allow users to harvest with their delegated key on that node.
        The NIS configuration has entries for configuring the maximum number of allowed harvesters
        and optionally allow harvesting only for certain account addresses. The unlock info gives
        information about the maximum number of allowed harvesters and how many harvesters are already
        using the node.
    </p>

    <api post>/account/unlocked/info</api>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p class=NemNoSpacing>Request cannot be performed in a browser.</p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
    "num-unlocked" : 2,
    "max-unlocked" : 3
}
    </resp>

    <h4>Possible Errors:</h4>

    <p>None</p>

    <h2>Retrieving historical account data</h2>

    <p>The configuration for NIS offers the possibility for a node to expose additional features
        that other nodes don't want to offer. One of those features is the supply of historical account
        data like balance and importance information. To turn on this feature for your NIS, you need to add
        HISTORICAL_ACCOUNT_DATA to the list of optional features in the file config-user.properties.</p>

    <api get>/account/historical/get</api>

    <desc>
        <p class=NemNoSpacing>Gets historical information for an account.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>address</p>
            </td>
            <td>
                <p class=NemNoSpacing>The address of the account.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>startHeight</p>
            </td>
            <td>
                <p class=NemNoSpacing>The block height from which on the data should be supplied.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>endHeight</p>
            </td>
            <td>
                <p class=NemNoSpacing>The block height up to which the data should be supplied.
                    The end height must be greater than or equal to the start height.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>increment</p>
            </td>
            <td>
                <p class=NemNoSpacing>The value by which the height is incremented between each data point.
                    The value must be greater than 0. NIS can supply up to 1000 data points with one request.
                    Requesting more than 1000 data points results in an error.</p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p>
        <a href="http://bigalice3.nem.ninja:7890/account/historical/get?address=NALICELGU3IVY4DPJKHYLSSVYFFWYS5QPLYEZDJJ&amp;startHeight=17592&amp;endHeight=17592&amp;increment=1">
            http://bigalice3.nem.ninja:7890/account/historical/get?address=NALICELGU3IVY4DPJKHYLSSVYFFWYS5QPLYEZDJJ&amp;startHeight=17592&amp;endHeight=17592&amp;increment=1</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
    [
        {
          "height": 17592,
          "address": "NALICELGU3IVY4DPJKHYLSSVYFFWYS5QPLYEZDJJ",
          "balance": 509676000000,
          "vestedBalance": 100999147150,
          "unvestedBalance": 408676852850,
          "importance": 0.00008857563463531297,
          "pageRank": 0.0007605047835049349
        }
    ]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the address is invalid, the start height is larger than the endheight, the increment
        is not a positive or the request results in more than 1000 data points an error is returned.</p>

    <h1>Block chain related requests</h1>

    <p>NEM builds a block chain which contains every
        bit of information needed. Subsequent blocks in the block chain have increasing
        heights that differ by one. Each block can contain transactions. Transactions
        build the basis of all account activity. It is therefore important to
        understand the concept and the structures of blocks and transactions.</p>

    <p>Blocks are generated by accounts. If an
        account generates a block and the block gets included in the block chain, the
        generating account, called the harvester, gets all the transaction fees for
        transactions that are included in the block. A harvester will therefore usually
        include as many transactions as possible.</p>

    <p>Transactions reflect all account
        activities. In order for a client to have an up to date balance for every
        account it is crucial to know about every transaction that occurred and
        therefore the client must have knowledge about every single block in the chain
        (one says: the client must be synchronized with the block chain).</p>

    <p>Whenever timestamps are used, the time
        reflects the network time. NEM has a time synchronization mechanism which lets
        all node agree on how many seconds since the nemesis have elapsed. This common
        time is called network time.</p>

    <p>The following chapters will first introduce
        the fields used in the block and transaction structure and then explain how a
        client can request parts of the block chain.</p>

    <p>Blocks are transferred using a JSON Block
        object.
        <appa>Block</appa>
        has more information and an example JSON Block object. The
        following fields are in the structure:
    </p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>timeStamp</p>
            </td>
            <td>
                <p>The network time when the block was created.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>signature</p>
            </td>
            <td>
                <p>The signature of the block. All blocks in the chain are signed by
                    the harvesters.</p>

                <p>This way any node can check if the block has been altered by some
                    evil entity.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>prevBlockHash</p>
            </td>
            <td>
                <p>The sha3-256 hash of the previous block as hexadecimal string.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>type</p>
            </td>
            <td>
                <p>The block type. There are currently two block types used:</p>
                <vals>
                    -1: Nemesis block type. This block type appears only once in the chain.
                    1: Regular block type. All blocks with height &gt; 1 have this type.
                </vals>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>transactions</p>
            </td>
            <td>
                <p>The array of transactions. See
                    <appa>Transaction</appa>
                    for more details. A block can contain up to 120 transactions.
                </p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>version</p>
            </td>
            <td>
                <p>The block version. The following versions are supported:</p>
                <li>0x68 &lt;&lt; 24 + 1 (1744830465 as 4 byte integer): the main network version</li>
                <li>0x60 &lt;&lt; 24 + 1 (1610612737 as 4 byte integer): the mijin network version</li>
                <li>0x98 &lt;&lt; 24 + 1 (-1744830463 as 4 byte integer): the test network version</li>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>signer</p>
            </td>
            <td>
                <p>The public key of the harvester of the block as hexadecimal
                    string.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>height</p>
            </td>
            <td>
                <p>The height of the block. Each block has a unique height.
                    Subsequent blocks differ in height by 1.</p>
            </td>
        </tr>
    </table>

    <p>Transactions were already discussed in
        chapter 2 <a href="#account-related-requests">Account related requests</a>. See also
        <appa>Transaction</appa>
        for an example JSON transaction object.
    </p>

    <h2>Requesting the block chain status information</h2>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Block chain height</h3>

    <api get>/chain/height</api>


    <desc>
        <p class=NemNoSpacing>Gets the current height of the block chain.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/chain/height">http://127.0.0.1:7890/chain/height</a></p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
       "height": 42799
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Block chain score</h3>

    <api get>/chain/score</api>

    <desc>
        <p class=NemNoSpacing>Gets the current score of the block
            chain. The higher the score, the better the chain. During synchronization,
            nodes try to get the best block chain in the network.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/chain/score">http://127.0.0.1:7890/chain/score</a></p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
       "score": "18722d5a7d590deb"
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Last block of the block chain score</h3>

    <api get>/chain/last-block</api>


    <desc>
        <p class=NemNoSpacing>Gets the current last block of the
            chain.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/chain/last-block">http://127.0.0.1:7890/chain/last-block</a></p>

    <h4>Example of returned JSON object (main network):</h4>

    <resp>
{
       "timeStamp": 9232968,
       "signature": "0a1351ef3e9b19c601e804a6d329c9ade662051d1da2c12c3aec9934353e421c79de7d8e59b127a8ca9b9d764e3ca67daefcf1952f71bc36f747c8a738036b05",
       "prevBlockHash": {
              "data": "58efa578aea719b644e8d7c731852bb26d8505257e03a897c8102e8c894a99d6"
       },
       "type": 1,
       "transactions": [
       ],
       "version": 1744830465,
       "signer": "2afca04d2cb8d16cf3656274bc55b95e60be823cfb7230d82f791ed42a309ee7",
       "height": 42804
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <h2>Requesting parts of the block chain</h2>

    <p>NIS can supply either individual blocks
        identified by block height or block hash or can supply up to 10 blocks
        beginning at a certain height.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Getting a block with a given height</h3>

    <api post>/block/at/public</api>


    <desc>
        <p class=NemNoSpacing>Gets a block from the chain that has the given height.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>blockHeight </p>
            </td>
            <td>
                <p class=NemNoSpacing>A BlockHeight JSON object as described
                    in
                    <appa>BlockHeight</appa>
                    .
                </p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p class=NemNoSpacing>Request cannot be performed in a browser.</p>

    <h4>Example of returned JSON object (test network):</h4>

    <resp>
{
       "timeStamp": 9232942,
       "signature": "005f91b8908fc173a428ff8e8c4a0ee0d69e4004aed0d08f27690b6b6672ef74ccc6b89695bed5f29b0f4a812cb84bfa459f52a4e14a11e574793969f0e1a30f",
       "prevBlockHash": {
              "data": "f721e563b4431594c5af6f6be0a913f47f0aca6c3b8ee6a703bfe175ee54babf"
       },
       "type": 1,
       "transactions": [
       ],
       "version": -1744830463,
       "signer": "78e121cc1cf63424651ec64251e78efda81386c9f5e9eb4cb08b2a2192c9dce5",
       "height": 42803
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the block with the specified height
        cannot be found in the database, NIS will return a JSON error object. See
        <appa>Error object</appa>
        or more information of the error object and
        <alnk>Appendix B: NIS Errors</alnk>
        the error message.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Getting part of a chain</h3>

    <api post>/local/chain/blocks-after</api>


    <desc>
        <p class=NemNoSpacing>Gets up to 10 blocks after given block height from the chain.
            If the database contains less than 10 block after the given height, then less blocks are returned.
            The returned data is an array of <a href="#explorerBlockViewModel">ExplorerBlockViewModel</a> JSON objects.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>blockHeight </p>
            </td>
            <td>
                <p class=NemNoSpacing>A BlockHeight JSON object as described
                    in
                    <appa>BlockHeight</appa>
                    .
                </p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p class=NemNoSpacing>Request cannot be performed in a browser.</p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
    "data":[{
        "txes":[{
            "tx": &lt;ExplorerViewModelTransaction&gt;
            "tx": &lt;ExplorerViewModelTransaction&gt;
        }],
        "block": &lt;Block&gt;
        "hash":"8ca8a3e01ac0eb482e668fda74141984ba118b027fc5f1f67d2d36a38bf48c49"
    }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>If the block height supplied is not
        positive, NIS will return a JSON error object. See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <h1>Node related requests</h1>

    <p>Nodes are the entities that exchange data
        in a network. A node is essentially a NIS instance running on a computer. To be
        able to communicate with the network, a node needs to be booted. Through node
        requests it is possible to discover other nodes in the network, learn about
        other nodes experiences and get information about their current chain height.</p>

    <p>Node structure consists of 3 parts:
        identity, endpoint and meta data:</p>

    <p>Every node is tied to an identity which is
        represented by an account. That way nodes are easier to identify. A node is
        given an identity during the boot process.</p>

    <p>The endpoint of a node holds information
        about the IP address, the port and the protocol used for communication.</p>

    <p>The meta data holds additional information
        about the NIS version and the platform NIS is running on.</p>

    <p>A node groups the set of neighbor nodes
        into several subsets by assigning a status to each node. The possible statuses
        are:</p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>active</p>
            </td>
            <td>
                <p>Nodes that have this status can be successfully communicated with.
                    Whenever a node is selecting a node for communication, it will pick a node
                    from the set of active nodes.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>inactive</p>
            </td>
            <td>
                <p>Inactive nodes are nodes with which it is not possible to
                    establish a connection.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>busy</p>
            </td>
            <td>
                <p>A node is set to status 'busy' if a connection can be established
                    but the node did not answer a request within a certain time limit.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>failure</p>
            </td>
            <td>
                <p>The status failure is assigned to a remote node in case there is
                    severe error during communication. This can for instance be due to the remote
                    node using a different protocol or the remote node using an identity
                    different from what was expected.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>unknown</p>
            </td>
            <td>
                <p>This status is given to a node if there is no information about
                    the status available.</p>
            </td>
        </tr>
    </table>

    <p>
        <appa>Node</appa>
        has more information and an example JSON Node object. A node object has the following fields:
    </p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>name</p>
            </td>
            <td>
                <p>The name of the node. This can be any string.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>public-key</p>
            </td>
            <td>
                <p>The public key used to identify the node.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>protocol</p>
            </td>
            <td>
                <p>The protocol used for the communication (currently only HTTP is
                    supported).</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>port</p>
            </td>
            <td>
                <p>The port used for the communication.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>host</p>
            </td>
            <td>
                <p>The IP address of the endpoint.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>application</p>
            </td>
            <td>
                <p>The name of the application that is running the node.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>version</p>
            </td>
            <td>
                <p>The version of the application.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>platform</p>
            </td>
            <td>
                <p>The underlying platform (OS, java version).</p>
            </td>
        </tr>
    </table>

    <h2>Requesting information about a node</h2>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Basic node information</h3>

    <api get>/node/info</api>


    <desc>
        <p class=NemNoSpacing>Gets basic information about a node.
            Using IP 127.0.0.1 gets information about the local node.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/node/info">http://127.0.0.1:7890/node/info</a></p>

    <h4>Example of returned JSON <a href="#node">Node</a></h4>

    <resp>
{
       "metaData":
       {
              "application": "NIS",
              "version": "0.4.33-BETA",
              "platform": "Oracle Corporation (1.8.0_25) on Windows 8"
       },
       "endpoint":
       {
              "protocol": "http",
              "port": 7890,
              "host": "81.224.224.156"
       },
       "identity":
       {
              "name": "Alice",
              "public-key": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
       }
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>In case the node has not been booted
        yet, NIS will return a JSON error object. See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Extended node information</h3>

    <api get>/node/extended-info</api>


    <desc>
        <p class=NemNoSpacing>Gets extended information about a node.
            Using IP 127.0.0.1 gets extended information about the local node.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/node/extended-info">http://127.0.0.1:7890/node/extended-info</a></p>

    <h4>Example of returned JSON <a href="#nisNodeInfo">NisNodeInfo</a> object:</h4>

    <resp>
{
       "node": {
              "metaData":
              {
                     "application": "NIS",
                     "version": "0.4.33-BETA",
                     "platform": "Oracle Corporation (1.8.0_25) on Windows 8"
              },
              "endpoint":
              {
                     "protocol": "http",
                     "port": 7890,
                     "host": "81.224.224.156"
              },
              "identity":
              {
                     "name": "Alice",
                     "public-key": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
              }
       },
       "nisInfo":
       {
              "currentTime": 9288341,
              "application": "NEM Infrastructure Server",
              "startTime": 9238484,
              "version": "0.4.33-BETA",
              "signer": "CN=VeriSign Class 3 Code Signing 2010 CA,OU=Terms of use at https://www.verisign.com/rpa (c)10,OU=VeriSign Trust Network,O=VeriSign\\, Inc.,C=US"
       }
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>In case the node has not been booted
        yet, NIS will return a JSON error object. See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <h2>Request for discovering the neighborhood of a node</h2>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Complete neighborhood</h3>

    <api get>/node/peer-list/all</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of all known nodes in the
            neighborhood.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/node/peer-list/all">http://127.0.0.1:7890/node/peer-list/all</a></p>

    <h4>Example of returned JSON <a href="#nodeCollection">NodeCollection</a> object (&lt;Node&gt;
        denotes a <a href="#node">Node</a> object):</h4>

    <resp>
{
       "inactive": [
              &lt;Node&gt;,
              &lt;Node&gt;
       ],
       "active": [
              &lt;Node&gt;,
              &lt;Node&gt;
       ],
       "busy": [
              &lt;Node&gt;,
              &lt;Node&gt;
       ],
       "failure": [
              &lt;Node&gt;,
              &lt;Node&gt;
       ]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>In case the node has not been booted
        yet, NIS will return a JSON error object. See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Reachable neighborhood</h3>

    <api get>/node/peer-list/reachable</api>


    <desc>
        <p>Gets an array of all nodes with status 'active' in the neighborhood.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/node/peer-list/reachable">http://127.0.0.1:7890/node/peer-list/reachable</a></p>

    <h4>Example of returned JSON <a href="#nodeCollection">NodeCollection</a> object (&lt;Node&gt;
        denotes a <a href="#node">Node</a> object):</h4>

    <resp>
{
       "data": [
              "metaData":
              {
                     "application": "NIS",
                     "version": "0.4.33-BETA",
                     "platform": "Oracle Corporation (1.8.0_25) on Windows 8"
              },
              "endpoint":
              {
                     "protocol": "http",
                     "port": 7890,
                     "host": "81.224.224.156"
              },
              "identity":
              {
                     "name": "Alice",
                     "public-key": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
              }
       ]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>In case the node has not been booted
        yet, NIS will return a JSON error object. See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Active neighborhood</h3>

    <api get>/node/peer-list/active</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of active nodes in the
            neighborhood that are selected for broadcasts.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/node/peer-list/active">http://127.0.0.1:7890/node/peer-list/active</a></p>

    <h4>Example of returned JSON <a href="#nodeCollection">NodeCollection</a> object (&lt;Node&gt;
        denotes a <a href="#node">Node</a> object):</h4>

    <resp>
{
       "data": [
              "metaData":
              {
                     "application": "NIS",
                     "version": "0.4.33-BETA",
                     "platform": "Oracle Corporation (1.8.0_25) on Windows 8"
              },
              "endpoint":
              {
                     "protocol": "http",
                     "port": 7890,
                     "host": "81.224.224.156"
              },
              "identity":
              {
                     "name": "Alice",
                     "public-key": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
              }
       ]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>In case the node has not been booted
        yet, NIS will return a JSON error object. See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Maximum chain height in the active neighborhood</h3>

    <api get>/node/active-peers/max-chain-height</api>


    <desc>
        <p class=NemNoSpacing>Requests the chain height from every
            node in the active node list (described in <a href="#active-neighborhood">Active neighborhood</a>) and returns the maximum height seen.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/node/active-peers/max-chain-height">http://127.0.0.1:7890/node/active-peers/max-chain-height</a></p>

    <h4>Example of returned JSON <a href="#blockHeight">BlockHeight</a> object:</h4>

    <resp>
{
       "height": 43920
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>In case the node has not been booted
        yet, NIS will return a JSON error object. See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Requesting node experiences</h2>

    <api get>/node/experiences</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of node experiences from
            another node. Each node saves its experiences with other nodes in an internal
            map. Sharing experiences helps nodes to select honest nodes for communication.</p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/node/experiences">http://127.0.0.1:7890/node/experiences</a></p>

    <h4>Example of returned array of JSON <a href="#extendedNodeExperiencePair">ExtendedNodeExperiencePair</a> objects:</h4>

    <resp>
{
       "data": [
       {
              "node":
              "metaData":
              {
                     "application": "NIS",
                     "version": "0.4.33-BETA",
                     "platform": "Oracle Corporation (1.8.0_25) on Windows 8"
              },
              "endpoint":
              {
                     "protocol": "http",
                     "port": 7890,
                     "host": "81.224.224.156"
              },
              "identity":
              {
                     "name": "Alice",
                     "public-key": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
              },
              "syncs": 3,
              "experience":
              {
                     "s": 1,
                     "f": 0
              }
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>In case the node has not been booted
        yet, NIS will return a JSON error object. See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Booting the local node</h2>

    <api post>/node/boot</api>

    <desc>
        <p class=NemNoSpacing>Boots the local node and thus assign an account (the identity) to the local node.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>bootNodeRequest </p>
            </td>
            <td>
                <p class=NemNoSpacing>A BootNodeRequest JSON object as
                    described in
                    <appa>BootNodeRequest</appa>
                    .
                </p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p class=NemNoSpacing>Request cannot be performed in a
        browser.</p>

    <h4>No return value</h4>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>In case the node has already been booted, NIS will return a JSON error object. See
        <appa>Error object</appa>
        for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <h1>Namespaces and Mosaics</h1>

    <h2>Namespaces</h2>

    <p>NEM supports the concept of namespaces which is the NEM analog of internet domain names.
        A namespace is an identification string that consists of one or more parts that are concatenated by dots, for example 'makoto.metals.silver'.
        All namespaces are unique and thus can only have one owner at a time.
        A namespace that has only one part is called a root namespace, otherwise sub-namespace.
        Root namespaces can be rented by accounts for the duration of one year. One month before the root namespace expires the rental contract
        can be renewed for another year. If a root namespace rental contract is renewed, all sub-namespaces are valid for another year as well.
        If the root namespace is not renewed, it exires together with all sub-namespaces. One month after a root namespace expires,
        another account is able to rent that root namespace. The new owner does not inherit the sub-namespaces from the previous owner however.
        An account can only rent a sub-namespace if it owns the corresponding root namespace.
    </p>

    <p>
        Namespaces have certain restrictions with respected to the characters being allowed in the parts as well as the length of a part. A root namespace
        may have a length of 16 characters while sub-namespaces may have a length of 64 characters. Valid characters are:
    <li>a, b, c, ..., z, A, B, C, ..., Z, 0, 1, 2, ..., 9, _ , -</li>
    However a part is only allowed to begin with a letter from the alphabet, thus 'alice' is an allowed part for a root namespace while '1alice' is not.
    Certain strings are reserved and thus not allowed as namespace parts. Among the disallowed namespace parts are
    <li>nem, user, account, org, com, biz, net, edu, mil, gov and info.</li>
    This list is not final and can be extended in the future. Thus 'user.alice' or 'alice.user' are not allowed in the NEM namespace system.
    The namespace may have up to 3 parts, thus 'makoto.metals.silver' is valid while 'makoto.metals.silver.coin' is not.
    </p>

    <p>
        A namespace rental contract is done via a
        <appa>ProvisionNamespaceTransaction</appa>
        . In addition to the usual transaction fee there is a rental
        fee. This fee is paid to the so called rental fee sink which is a special account with address
    <li>NAMESPACEWH4MKFMBCVFERDPOOP4FK7MTBXDPZZA in the main net and</li>
    <li>TAMESPACEWH4MKFMBCVFERDPOOP4FK7MTDJEYP35 in the test net.</li>
    The fee for renting a namespace for one year is
    <li>50000 XEM for a root namespace and</li>
    <li>5000 XEM for a sub-namespace.</li>
    </p>

    <p>
        The ownership of a namespace is needed in order to create mosaics.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Retrieving root namespaces</h3>

    <api get>/namespace/root/page</api>


    <desc>
        <p class=NemNoSpacing>Gets the root namespaces. The requests supports paging, i.e. retrieving the root namespaces in batches of a specified size.
            The request returns an array of <a href="#namespaceMetaDataPair">NamespaceMetaDataPair</a> objects.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>id</p>
            </td>
            <td>
                <p class=NemNoSpacing>The topmost namespace database id up to which root namespaces are returned. The parameter is optional.
                    If not supplied the most recent rented root namespaces are returned.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>pagesize</p>
            </td>
            <td>
                <p class=NemNoSpacing>The number of namespace objects to be returned for each request. The parameter is optional.
                    The default value is 25, the minimum value is 5 and hte maximum value is 100.</p>
            </td>
        </tr>
    </table>
    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/namespace/root/page?id=26754&pageSize=35">http://127.0.0.1:7890/namespace/roots?id=26754&pageSize=35</a></p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
        "data": [{
            "meta":{
                "id":26264,
            },
            "namespace":{
                "fqn": "makoto.metal.coins",
                "owner": TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
                "height": 13465
            }
        },{
            "meta":{
                "id":25421,
            },
            "namespace":{
                "fqn": "gimre.vouchers",
                "owner": TDGIMREMR5NSRFUOMPI5OOHLDATCABNPC5ID2SVA",
                "height": 12392
            }
        }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Retrieving a specific namespace</h3>

    <api get>/namespace</api>


    <desc>
        <p class=NemNoSpacing>Gets the namespace with given id.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>namespace</p>
            </td>
            <td>
                <p class=NemNoSpacing>The namespace id.</p>
            </td>
        </tr>
    </table>
    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/namespace?namespace=makoto.metal.coins">http://127.0.0.1:7890/namespace?namespace=makoto.metal.coins</a></p>

    <h4>Example of returned JSON object:</h4>

    <resp>
{
        "fqn": "makoto.metal.coins",
        "owner": TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
        "height": 13465
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>NIS returns an error if the namespace parameter is missing or invalid.
        See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <h2>Mosaics</h2>

    <p>
        NEM mosaics are assets that expose additional properties and other features. Each mosaic has an underlying mosaic definition.
        To be able to create a mosaic definition, an account must rent at least one root namespace which the mosaic definition can then refer to.
        The basic data for a mosaic definition consists of
    <li>
        <b>mosaic id</b>: the mosaic id consists of two parts, a namespace id and a mosaic name. When representing the mosaic id as string
        the two parts are concatenated via a '*':<br>
        For example if the namespace id is 'makoto.metals.silver' and the mosaic name is 'coin' then the string representation would be 'makoto.metals.silver *
        coin'.
        Since mosaic ids should be unique, the mosaic name has to be unique within the namespace the mosaic definition refers to. The maximum length for a
        mosaic name is 32 characters. Allowed characters are
        <ol>
            <li>a, b, c, ..., z, 0, 1, 2, ..., 9, ', _ , -</li>
        </ol>
        but the first character must be a letter from the alphabet.
    </li>
    <li>
        <b>description</b>: Each definition needs a description of the mosaic. The description may not exceed a length of 512 characters. There is no
        limitation for the characters used in the description.
    </li>
    <li>
        <b>properties</b>: The behavior of a mosaic can be customized by a set of properties. If no properties are supplied then default properties are applied.
        Supported properties are:
        <ol>
            <li><b>initialSupply</b>: The creator can specify an initial supply of mosaics when creating the definition.
                The supply is given in entire units of the mosaic, <b>not</b> in smallest sub-units. The initial supply must be in the range
                of 0 and 9,000,000,000. The default value is "1000".
            </li>
            <li><b>divisibility</b>: The divisibility determines up to what decimal place the mosaic can be divided into. Thus a divisibility of 3
                means that a mosaic can be divided into smallest parts of 0.001 mosaics, i.e. milli mosaics is the smallest sub-unit.
                When transferring mosaics via a transfer transaction the quantity transferred is given in multiples of those smallest parts.<br>
                The divisibility must be in the range of 0 and 6. The default value is "0".
            </li>
            <li><b>supplyMutable</b>: The creator can choose between a definition that allows a mosaic supply change at a later point or an immutable supply.
                Allowed values for the property are "true" and "false". The default value is "false".
            </li>
            <li><b>transferable</b>: The creator can choose if the mosaic definition should allow for transfers of the mosaic among accounts other than
                the creator. If the property 'transferable' is set to "false", only transfer transactions having the creator as sender or as recipient
                can transfer mosaics of that type. If set to "true" the mosaics can be transferred to and from arbitrary accounts.
                Allowed values for the property are thus "true" and "false". The default value is "true".
            </li>
        </ol>
    </li>
    <li>
        <b>levy</b>: The creator can demand that for each transfer of a mosaic of that type a special fee is collected from the sender and send to an
        account of his choice (thus the creator can specify his own account as recipient of this fee). The data for the levy is the following:
        <ol>
            <li><b>fee type:</b> There are two fee types supported, absolute fee and percentile fee.
                <ol>
                    <li>absolute fee:</li>
                    The fee is specified as absolute quantity and thus does not depend on the quantity that is transferred.
                    <li>percentile fee:</li>
                    The fee is specified as multiple of the percentile of the quantity that is transferred. The fee is thus
                    linearly increasing with the transferred mosaic quantity.
                </ol>
            </li>
            <li><b>recipient:</b> The recipient of the levy. This can be any account.</li>
            <li><b>mosaic id:</b> The id of the mosaic in which the fee has to be paid. Any existing mosaic id can be specified.
                If the creator wants the fee to be paid in XEM, then (s)he has to use the mosaic id 'nem * xem'.
            </li>
            <li><b>fee:</b> The fee quantity. The interpretation is dependent on the field 'fee type', see above.</li>
        </ol>
    </li>
    </p>

    <p>
        A mosaic definition can be created via a
        <appa>MosaicDefinitionCreationTransaction</appa>
        . In addition to the usual transaction fee there is a creation
        fee. This fee is paid to the so called creation fee sink which is a special account with address
    <li>NBMOSAICOD4F54EE5CDMR23CCBGOAM2XSIUX6TRS in the main net and</li>
    <li>TBMOSAICOD4F54EE5CDMR23CCBGOAM2XSJBR5OLC in the test net.</li>
    The fee for creating a mosaic definition is 50000 XEM.
    </p>

    <p>There is one predefined mosaic which represents the XEM coin. The data for this XEM mosaic is:
    <li>namespace: nem</li>
    <li>name: xem</li>
    <li>initial supply: 8,999,999,999</li>
    <li>divisibility: 6</li>
    <li>supply mutable: false</li>
    <li>transferable: true</li>
    <li>levy: none</li>
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h3>Retrieving mosaic definitions</h3>

    <api get>/namespace/mosaic/definition/page</api>


    <desc>
        <p class=NemNoSpacing>Gets the mosaic definitions for a given namespace. The request supports paging.
            The request return an array of <a href="#mosaicDefinitionMetaDataPair">MosaicDefinitionMetaDataPair</a> objects.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>namespace</p>
            </td>
            <td>
                <p class=NemNoSpacing>The namespace id.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>id</p>
            </td>
            <td>
                <p class=NemNoSpacing>The topmost mosaic definition database id up to which root mosaic definitions are returned. The parameter is optional.
                    If not supplied the most recent mosaic definitiona are returned.</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>pagesize</p>
            </td>
            <td>
                <p class=NemNoSpacing>The number of mosaic definition objects to be returned for each request. The parameter is optional.
                    The default value is 25, the minimum value is 5 and hte maximum value is 100.</p>
            </td>
        </tr>
    </table>
    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/namespace/mosaic/definition/page?namespace=makoto.metal.coins">http://127.0.0.1:7890/namespace/mosaic/definition/page?namespace=makoto.metal.coins</a>
    </p>

    <h4>Example of returned JSON object:</h4>

    <resp>
 {
    "data": [{
        "meta" {
            "id": 3541
        },
        "mosaic": {
            "creator": "10cfe522fe23c015b8ab24ef6a0c32c5de78eb55b2152ed07b6a092121187100",
            "id": {
                "namespaceId": "makoto.metal.coins",
                "name": "silver coin"
            },
            "description": "Real silver coins, pure silver",
            "properties": [{
                 "name": "divisibility",
                 "value": "0"
            },{
                "name": "initialSupply",
                "value": "1000"
            },{
                "name": "supplyMutable",
                "value": "false"
            },{
                "name": "transferable",
                "value": "true"
            }]
        }
    }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>NIS returns an error if the namespace parameter is missing or invalid.
        See
        <alnk>Appendix B: NIS Errors</alnk>
        for details about errors.
    </p>

    <h1>Initiating transactions</h1>

    <p>Transactions are the way of transferring NEM and/or messages from one
        account to another. Once a transaction is initiated, it is still unconfirmed and
        thus not yet accepted by the network. At this point it is not yet clear if it will
        get included in a block. Never rely on a transaction which has the state
        'unconfirmed'. Once it is included in a block, the transaction gets processed and,
        in case of a transfer transaction, the amount stated in the transaction gets
        transferred from the sender's account to the recipient's account. Additionally
        the transaction fee is deducted from the sender's account. The transaction is
        said to have 0 confirmations at this point. When another block is added to the
        block chain the transaction has 1 confirmation. The next block added to the
        chain will give it 2 confirmations and so on.</p>

    <p>Crypto currencies have the ability to roll back part the block chain. This is
        essential for being able to resolve forks of the block chain. There is however
        a maximum number of blocks that can be rolled back, this is called the rewrite
        limit. Hence forks can only be resolved up to a certain depth too. NEM has
        a rewrite limit of 360 blocks. Once a transaction has more than 360
        confirmations, it cannot be reversed. In real life, forks that are deeper than
        20 blocks do not happen, unless there was some severe problem with the
        block chain due to a bug in the code or an attack of some kind.</p>

    <p>A client can initiate a transaction in two ways:</p>
    <li>
        If the client is not able to sign the transaction data it can let the local NIS
        do the signing by sending a RequestPrepareAnnounce JSON object to NIS. See
        <appa>RequestPrepareAnnounce</appa>
        for more details.

        <div class="warning">
            The <span class="JSON">/transaction/prepare-announce</span> API
            should be <br> used only on <strong>TRUSTED</strong> and <strong>LOCAL</strong> nodes!
        </div>

        <p>Note: keep in mind, that NCC does <strong>NOT</strong>
            use this API. It does all the transaction signing on it's own.
        </p>

    </li>
    <li>
        If the client has an ed25519 implementation and can thus sign the transaction it
        can send a RequestAnnounce JSON object to NIS. Doing so has the advantage that you
        can use an untrusted remote NIS for sending a transaction.
        See
        <appa>RequestAnnounce</appa>
        for more details on this object.
    </li>

    <p>Since most client with depend on a local NIS to create the transaction signature
        Chapters 6.1 through 6.6 will explain transaction related actions using the first way.
        Chapter 6.7 explains the steps you have to take to gather the data that needs to be signed
        and how to initiate a transaction the second way.
        Note however that we will not explain how to create the signature itself since this involves
        some cryptographical concepts which are out of the scope of this document.
    </p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Initiating a transaction</h2>

    <api post>/transaction/prepare-announce</api>

    <desc>
        <p class=NemNoSpacing>Creates and broadcasts a transaction.
            Since this request involves the private key of an account, it should only be
            sent to a <b>local</b> NIS.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>requestPrepareAnnounce</p>
            </td>
            <td>
                <p class=NemNoSpacing>A RequestPrepareAnnounce JSON object as described in
                    <appa>RequestPrepareAnnounce</appa>
                    .
                </p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p class=NemNoSpacing>Request cannot be performed in a
        browser.</p>

    <h4>Example of returned JSON <a href="#nemAnnounceResult">NemAnnounceResult</a> object:</h4>

    <resp>
{
   "type":1,
   "code":1,
   "message":"SUCCESS",
   "transactionHash": {
      "data":"c1786437336da077cd572a27710c40c378610e8d33880bcb7bdb0a42e3d35586"
   },
   "innerTransactionHash": {
      "data":"cc317a7674d56352b4c711096a7594bd11908bf518293a191fc2faa12eac0fbb"
   }
}
    </resp>

    <h4>Possible Errors:</h4>

    <p>There are various errors that can occur due
        to failure of transaction validation See
        <appa>Error object</appa>
        <b> </b>for more information of the error
        object and
        <alnk>Appendix B: NIS Errors</alnk>
        for the error message.
    </p>

    <p>The most common errors are:</p>

    <ul>
        <li>The sender account has not enough funds.</li>
        <li>The timestamp is invalid because it lies too far in the future.</li>
        <li>The deadline is invalid because it has already been passed.</li>
        <li>The attached message is too large.</li>
        <li>The transaction is already known.</li>
        <li>There is another transaction conflicting with this transaction. This can happen when trying to transfer the importance to another account.</li>
    </ul>

    <h2>Initiating a transfer transaction</h2>

    <p>NIS supports transfer transactions having version 1 or 2. Transfer transactions with version 1 can only transfer a message and XEM coins
        while version 2 transfer transactions can transfer a set of mosaics too.</p>

    <h3>Version 1 transfer transactions</h3>

    <p>Suppose you want to send 1000 NEM from sender account (referred hereafter as <em><b>'Alice'</b></em>):</p>

    <p class="JSON">TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS</p>

    <p>to recipient account: </p>

    <p class="JSON">TBOBBSXX7BESJXDWGLP5Z7FM5HSTKUH5WIMPW562</p>

    <p>The RequestPrepareAnnounce JSON object you have to send to NIS via a POST request would look similar to this (test network):</p>

    <pre><code class="JSON">
{
        "transaction":
        {
            "timeStamp": 9111526,
            "amount": 1000000000,
            "fee": 3000000,
            "recipient": "TBOBBSXX7BESJXDWGLP5Z7FM5HSTKUH5WIMPW562",
            "type": 257,
            "deadline": 9154726,
            "message":
            {
                "payload": "",
                "type": 1
            },
            "version": -1744830463,
            "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
        },
        "privateKey": "00983bb01d05edecfaef55df9486c111abb6299c754a002069b1d0ef4537441bda"
}
    </code></pre>

    <p>Note that there is no signature in the transaction part of the object since NIS will create the signature for you.
        Note also that the field 'version' contains both the network version and the transaction version as can be see when converting
        the value to the hexadecimal system: -1744830463 = 0x98000001 (network version 0x98 and transaction version 0x01).
        If the sender account has enough funds for the transaction NIS would respond with the JSON object</p>

    <resp>
{
        "type": 1,
        "code": 1,
        "message": "SUCCESS",
        "transactionHash": {
            "data":"c1786437336da077cd572a27710c40c378610e8d33880bcb7bdb0a42e3d35586"
        },
        "innerTransactionHash": {}
}
    </resp>

    <h3>Version 2 transfer transactions</h3>

    <p>With transfer transactions version 2 you can just transfer messages and XEM as described in the previous chapter, the only difference
        being the field version which should have the value -1744830462 = 0x98000002 for testnet, 1744830466 = 0x68000002 for mainnet
        or 1610612738 = 0x60000002 for mijin network. </p>

    <p>However, version 2 transfer transaction are more powerful as they let you transfer mosaics too.<br>
        Suppose you already have created a mosaic with id 'makoto.metals.silver * coin' with a divisibility of 0 and you want bundle the transfer
        of those silver coin mosaics with a transfer of 100 XEM for each silver coin. For transferring 3 silver coin mosaics and 300 XEM with a single
        transfer transaction you would issue a RequestPrepareAnnounce JSON object to NIS which looks like this:</p>

    <pre><code class="JSON">
{
        "transaction":
        {
            "timeStamp": 9111526,
            "amount": 3000000,
            "fee": 30000000,
            "recipient": "TBOBBSXX7BESJXDWGLP5Z7FM5HSTKUH5WIMPW562",
            "type": 257,
            "deadline": 9154726,
            "message":
            {
                "payload": "",
                "type": 1
            },
            "version": -1744830462,
            "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
            "mosaics":[{
                "mosaicId":{
                    "namespaceId": "makoto.metals.silver",
                    "name": "coin"
                },
                "quantity": 1
            },{
                "mosaicId":{
                    "namespaceId": "nem",
                    "name": "xem"
                },
                "quantity": 100000000
            }]
        },
        "privateKey": "00983bb01d05edecfaef55df9486c111abb6299c754a002069b1d0ef4537441bda"
}
    </code></pre>

    <p>There are 2 mosaics attached to the transfer transaction:
    <li>A mosaic with id 'makoto.metals.silver * coin' and quantity 1 which represents 1 smallest unit available for the mosaic.
        Since the divisibility of that mosaic is 0 (as assumed above) the quantity represents 1 whole unit, i.e. 1 coin.
    </li>
    <li>A mosaic with id 'nem * xem' (which is the special XEM mosaic representing regular XEM coins) which has a divisibility of 6 and
        thus the quantity of 100000000 represents 100 XEM.
    </li>
    You can view the attachment as being a bag of mosaics holding in this example 1 silver coin mosaic and 100 XEM.
    </p>

    <p>The amount field of the transaction is interpreted differently for the transaction due to the attachment. The number to multiply the quantities
        given in the attachment is given by dividing the amount by 1,000,000 (as of this version NIS does not support fractional transfers). So in this
        example 3,000,000 / 1,000,000 = 3 and thus 3 times the attachment is transferred resulting in 3 silver coin mosaics and 300 XEM being transferred
        to the recipient.</p>

    <p>Common reason for the transaction to be rejected could be:
    <li>At least one mosaic specified in the attachment is unknown to NIS.</li>
    <li>The sender does not own enough mosaics of at least type specified in the attachment.</li>
    <li>At least one mosaic specified in the attachment is defined as not transferable and both sender and recipient are not the creator of that mosaic.</li>
    </p>

    <p>If the mosaic definition for the mosaic 'makoto.metals.silver * coin' has a levy section stating that for each transfer involving the silver coin mosaic
        10 XEM has to be paid to the recipient with address TDGOGOGOWZJ3HU4F6CUM5IKE7GHG4FFTF5BZ7JPW then the transfer transaction would automatically
        induce a transfer of 10 XEM from the transaction sender to TDGOGOGOWZJ3HU4F6CUM5IKE7GHG4FFTF5BZ7JPW.</p>

    <h2>Converting an account to a multisig account</h2>

    <p>NIS natively supports m of n multisig accounts. This means an account can be converted into a multisig account
        having n cosignatories and m of those cosignatories need to sign a transaction from the multisig account in order
        to complete the transaction.
        To convert a normal account to a multisig account an aggregate modification transaction
        (see
        <appa>MultisigAggregateModificationTransaction</appa>
        ) must be sent to the network.
        Assuming you want to convert <em>Alice</em> with public key:
    </p>
    <ul> Account <b>'Alice'</b>:
        <ul>
            <li>public key: <span class="JSON">a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a</span></li>
        </ul>
    </ul>

    <p>into a 2 of 3 multisig account meaning the account has 3 cosignatories and at least 2 cosignatories have to sign
        to complete a multisig transaction:</p>

    <ol>
        <li> Cosignatory <b>'Bob'</b>:
            <ul>
                <li>address: <span class="JSON">TBOBBSXX7BESJXDWGLP5Z7FM5HSTKUH5WIMPW562</span></li>
                <li>public key: <span class="JSON">6083df7119d43e815ed2967c795f806f6b73f8f92a56a7611e3848816ec50958</span></li>
            </ul>
        </li>
        <li>Cosignatory <b>'jusan'</b>:
            <ul>
                <li>address: <span class="JSON">TBJUSANZ63AKNJ57XMK6Y2IBH55UNNRXJFZRDTRW</span></li>
                <li>public key: <span class="JSON">0662ed29cbfa7038530fb7f52df865eed6708d51bc7a24bcd05db35185b53c70</span></li>
            </ul>
        </li>
        <li>Cosignatory <b>'go'</b>:
            <ul>
                <li>address: <span class="JSON">TDGOGOGOWZJ3HU4F6CUM5IKE7GHG4FFTF5BZ7JPW</span></li>
                <li>public key: <span class="JSON">cc61676a4275abcffd10a9ea1081091ff054a1a8a720429256aebf8034aab099</span></li>
            </ul>
        </li>
    </ol>

    <p>you would have to create a JSON object that looks similar to this (test network):</p>

    <pre><code class="JSON"> {
        "transaction":
        {
            "timeStamp": 9111526,
            "fee": 28000000,
            "type": 4097,
            "deadline": 9154726,
            "version": -1744830462,
            "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a",
            "modifications": [
                {
                    "modificationType": 1,
                    "cosignatoryAccount": "6083df7119d43e815ed2967c795f806f6b73f8f92a56a7611e3848816ec50958"
                },{
                    "modificationType": 1,
                    "cosignatoryAccount": "0662ed29cbfa7038530fb7f52df865eed6708d51bc7a24bcd05db35185b53c70"
                },{
                    "modificationType": 1,
                    "cosignatoryAccount": "cc61676a4275abcffd10a9ea1081091ff054a1a8a720429256aebf8034aab099"
                }
            ],
            "minCosignatories" : {
                "relativeChange": 2
            }
        },
        "privateKey": "00983bb01d05edecfaef55df9486c111abb6299c754a002069b1d0ef4537441bda"
        }</code></pre>

    <p>Note again that there is no signature since the transaction will be signed by NIS.</p>

    <p>After the transaction is signed by NIS and is accepted by the network by
        including it into a block, the account Alice is now a 2 of 3 multisig account.
        From this point on, only the cosignatories can initiate a transaction for the
        account <em>Alice</em>. Also, any transaction from account <em>Alice</em>
        must be a multisig transaction.</p>

    <h2>Initiating a multisig transaction</h2>

    <p>As stated above, only one of the cosignatories (<em>Bob, Jusan and Go</em>)
        can create a transaction for the account <em>Alice</em>.</p>

    <p>Lets assume <em>Bob</em> wants to start a transfer transaction which transfers
        1000 NEM from account <em>Alice</em> to account <em>Jusan</em>.<br>
        Since the account <em>Alice</em> is a multisig account the transfer transaction
        (in the JSON object the "otherTrans" structure) must be wrapped in
        a multisig transaction (see
        <appa>MultisigTransaction</appa>
        ).
        The corresponding RequestPrepareAnnounce object would look similar to this (test network):
    </p>

    <pre><code class="JSON"> {
        "transaction":
        {
            "timeStamp": 9111526,
            "fee": 3000000,
            "type": 4100,
            "deadline": 9154726,
            "version": -1744830463,
            "signer": "6083df7119d43e815ed2967c795f806f6b73f8f92a56a7611e3848816ec50958",
            "otherTrans": {
                "timeStamp": 9111526,
                "amount": 1000000000,
                "fee": 4000000,
                "recipient": "TBJUSANZ63AKNJ57XMK6Y2IBH55UNNRXJFZRDTRW",
                "type": 257,
                "deadline": 9154726,
                "message":
                {
                    "payload": "",
                    "type": 1
                },
                "version": -1744830463,
                "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
            },
            "signatures":[
            ]
        },
        "privateKey": "00a6e2526b5cc84f9174c4ff050ca352623061115951c649b36b08409c4ccb7b2e"
        }</code></pre>

    <p>NIS will sign the transaction and publish it. The returned
        <a href="#NemAnnounceResult">NemAnnounceResult</a> object this time
        contains the hash of the inner transaction (<i>otherTrans</i> in the above structure):</p>

    <pre><span class="JSON">    {
        "type": 1,
        "code": 1,
        "message": "SUCCESS"
        "transactionHash": {
            "data":"c1786437336da077cd572a27710c40c378610e8d33880bcb7bdb0a42e3d35586"
        },
        "innerTransactionHash": {
            <b>"data": "44e4968e5aa35fe182d4def5958e23cf941c4bf809364afb4431ebbf6a18c039"</b>
        }
    }</span></pre>

    <p>The hash is needed by the nodes that will create multisig signature transactions
        for the above transaction.</p>

    <p>At this point the transaction cannot (and will not) be included in a block
        because none of the other cosignatories - <em>Jusan</em> and <em>Go</em> - has
        signed the transaction yet &hellip;</p>

    <h3>Cosigning multisig transaction</h3>

    <p>&hellip; to do so, <em>Jusan</em> or <em>Go</em> must initiate a multisig signature transaction
        (see
        <appa>MultisigSignatureTransaction</appa>
        ).
        <em>Jusan</em> has to create a RequestPrepareAnnounce JSON object that looks similar to this (test network):
    </p>

    <pre><code class="JSON"> {
        "transaction":
        {
            "timeStamp": 9111526,
            "fee": 6000000,
            "type": 4098,
            "deadline": 9157365,
            "version": -1744830463,
            "signer": "0662ed29cbfa7038530fb7f52df865eed6708d51bc7a24bcd05db35185b53c70",
            "otherHash": {
                <b>"data": "44e4968e5aa35fe182d4def5958e23cf941c4bf809364afb4431ebbf6a18c039"</b>
            },
            <b>"otherAccount": "TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS"</b>
        },
        "privateKey": "00be34fdb20a9f6fed51376f0bab9f25ea7a48d610324588a6b203d0a1a6db4bc1"
        }</code></pre>

    <p>Note that <em>Jusan</em> used the hash ('otherHash') returned by NIS
        from <em>Bob's</em> request.</p>

    <p>After NIS has signed the transaction and sent it to the network,
        the signature transaction will be attached to the multisig transaction.<br>
        With <em>Jusan</em> having signed the multisig transaction that <em>Bob</em> initiated,
        two of the three cosignatories have signed the inner transfer transaction (<em>Bob</em>
        indirectly signed by initiating the multisig transaction) and thus the
        multisig transaction can be included in a block.
    </p>

    <h2>Adding and removing cosignatories</h2>

    <p>It is possible to modify the list of cosignatories for a multisig account. This is
        done via a aggregate modification transaction wrapped in a multisig transaction.</p>

    <p>Suppose you want to add the cosignatory <em>Hachi</em> to the multisig
        account <em>Alice</em> and increase the minimum of cosignatories required to complete
        a transaction from 2 to 3.</p>

    <ol start="4">
        <li> Cosignatory <b>'hachi'</b>:
            <ul>
                <li>address: <span class="JSON">TDHACHIMHRBBRHR57SR3BDBFFWDTYVSLGMFKIDOR</span></li>
                <li>public key: <span class="JSON">6c66ea288522990db7a0a63c9c20f532cdcb68dc3c9544fb20f7322c92ceadbb</span></li>
            </ul>
        </li>
    </ol>

    <p>To do that, one of the existing cosignatories (assuming here it is <em>Jusan</em>)
        must initiate the corresponding multisig transaction (test network):</p>
    
    <pre><code class="JSON">{
        "transaction":
        {
            "timeStamp": 9111526,
            "fee": 6000000,
            "type": 4100,
            "deadline": 9154726,
            "version": -1744830462,
            "signer": "6083df7119d43e815ed2967c795f806f6b73f8f92a56a7611e3848816ec50958",
            "otherTrans": {
                "timeStamp": 9111526,
                "fee": 16000000,
                "type": 4097,
                "deadline": 9154726,
                "version": -1744830462,
                "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a",
                "modifications": [
                    {
                    "modificationType": 1,
                    <b>"cosignatoryAccount": "6c66ea288522990db7a0a63c9c20f532cdcb68dc3c9544fb20f7322c92ceadbb"</b>
                    }
                ],
                "minCosignatories" : {
                    "relativeChange": 1
                }
            },
            "signatures":[
            ]
        },
        "privateKey": "00be34fdb20a9f6fed51376f0bab9f25ea7a48d610324588a6b203d0a1a6db4bc1"
        }</code> </pre>

    <p>After NIS has signed and broadcasted the transaction to the network, one of the other
        two cosignatories needs to sign the transaction as well as explained in
        <a href="#initiating-a-multisig-transaction">Initiating a multisig transaction</a>.
        After the transaction was successfully included in a block, the account <em>Alice</em>
        is a 3 of 4 multisig account.</p>

    <p>If at some later time <em>Bob, Jusan and Go</em> want to remove the
        cosignatory <em>Hachi</em> to make it a 2 of 3 multisig account again one of cosignatories could initiate a similar
        transaction as above but this time with <span class="JSON">"modificationType"</span>
        set to <b>2</b> (which means remove) and using a minimum cosignatories relative change value of <b>-1</b>.<br>
        For removing a cosignatory <em>all</em> cosignatories except the one being removed need to sign the transaction.
        Once approved by the network <em>Hachi</em> is no longer cosignatory of the multisig account <em>Alice.</em></p>

    <div class="warning">
        Removal of accounts is <strong>NOT</strong> final and might be subject of change
    </div>

    <h2>How to use a multisig account</h2>

    <p>The purpose of multisig accounts is to make accounts safer. But this relies
        on the user not making mistakes when using multisig accounts.<br>
        If for instance all private keys of the cosignatories of a multisig account
        reside on a single computer then the multisig account is essentially as good
        as a normal account because if that computer gets compromised all private
        keys are disclosed to the attacks at once.</p>

    <p>It is therefore essential to have the private key of the cosignatories on
        different computer preferably in different locations.</p>

    <p>If you have read
        "<a href="#initiating-a-multisig-transaction">Initiating a multisig transaction</a>"
        you know that the cosignatories of a multisig transaction must know the hash
        of the inner transaction in order to be able to sign the multisig transaction.
        There are two ways of gaining knowledge of that hash:</p>

    <ol>
        <li>The initiator of the multisig transaction writes down the hash (which is
            included in the returned JSON object by NIS) and sends the hash to the cosignatories.
        </li>
        <li>The cosignatories poll the unconfirmed transactions using their local NIS.
            As described in chapter
            <a href="#unconfirmed-transactions">Unconfirmed transactions</a>,
            the meta data part of an unconfirmed transaction JSON object contains
            the hash of the inner transaction in case of a multisig transaction.
        </li>
    </ol>

    <p>In first case the implementer of the client side software is responsible for
        transferring the hash to the cosignatories while in second case the NEM network
        will do it for you.</p>

    <p>The standard client NCC uses the second method. It lets you handle multisig accounts in a convenient way.</p>

    <p>
        Currently, we recommend to use at least three cosignatories in different locations when
        using the multisig account feature. If one of the cosignatory's private key gets
        compromised you should immediately remove that account from the list of
        cosignatories and afterwards add a new cosignatory
        (see chapter <a href="#adding-and-removing-cosignatories">Adding and removing cosignatories</a>
        on how to do this).</p>

    <p><b>If a private key is stored on a computer that computer should not be used
        for surfing the internet or doing other unsafe things.</b></p>

    <h2>Provisioning a namespace</h2>

    <p>This chapter explains what actions you have to take in order to provision (i.e. rent) a namespace.
        You can find a detailed description of namespaces in the chapter <a href="#namespaces">Namespaces</a>.
        Suppose you want to claim the root namespace 'alice' and the sub-namespace 'alice.vouchers'. The first action
        would be to issue an <a href="#provisionNamespaceTransaction">ProvisionNamespaceTransaction</a>. As usual this is done
        by sending a RequestPrepareAnnounce JSON object to NIS which in this case would look like this:
    </p>

        <pre><code class="JSON">
            {
            "transaction":
            {
                "timeStamp": 9111526,
                "fee": 108000000,
                "type": 8193,
                "deadline": 9154726,
                "version": -1744830463,
                "signer": "d99e88c90da71a4b0d848454e59e296c9ef7a8f018f3eaa3a198dc460b6621a4",
                "rentalFeeSink": "3e82e1c1e4a75adaa3cba8c101c3cd31d9817a2eb966eb3b511fb2ed45b8e262",
                "rentalFee": 50000000000,
                "newPart": "alice",
                "parent": null
            },
            "privateKey": "00983bb01d05edecfaef55df9486c111abb6299c754a002069b1d0ef4537441bda"
}
        </code></pre>

    <p>The field 'parent' is set to null indicating that you want to rent a root namespace. You also have to be sure that no one else
        has already rented that root namespace or NIS will return an error. The high rental fee is there to prevent users from squatting all
        kinds of root namespaces. This fee is not given to the harvesters because this would encourage harvesters to wait until they are
        allowed to harvest a block, include their provision namespace transaction in that block and thus essentially getting the namespace
        for free. Instead all rental fees are collected in a special multisig account.<br>
        The most common error responses from NIS will be:
    <li>The namespace is already owned by another account.</li>
    <li>The namespace contains illegal character or a reserved namespace part.</li>
    <li>The public key of the rental fee sink is invalid.</li>
    <li>The rental fee is invalid (i.e. too low).</li>
    If NIS responses with a success message, the transaction is broadcasted to the network and will get included in a future block.
    After the transaction is included in a block you can check that you are the owner of that namespace by issuing an /account/namespaces
    request, see chapter xyz.
    </p>

    <p>To rent the sub-namespace 'alice.vouchers' you need again send a RequestPrepareAnnounce JSON object to NIS which this time looks like this:</p>

         <pre><code class="JSON">
{
         "transaction":
         {
             "timeStamp": 9111526,
             "fee": 108000000,
             "type": 8193,
             "deadline": 9154726,
             "version": -1744830463,
             "signer": "d99e88c90da71a4b0d848454e59e296c9ef7a8f018f3eaa3a198dc460b6621a4",
             "rentalFeeSink": "3e82e1c1e4a75adaa3cba8c101c3cd31d9817a2eb966eb3b511fb2ed45b8e262",
             "rentalFee": 5000000000,
             "newPart": "vouchers",
             "parent": "alice"
         },
         "privateKey": "00983bb01d05edecfaef55df9486c111abb6299c754a002069b1d0ef4537441bda"
}
         </code></pre>

    <p>This time the parent is set to the parent namespace, in this case the root namespace 'alice'. The rental fee for a sub-namespace
        is 200 XEM. Be sure to wait until you own the root namespace or NIS will respond with
        an error message. Once the transaction is included in a block, you own the sub-namespace 'alice.vouchers' as long as the root namespace 'alice'
        does not expire.</p>

    <p>If you want to rent the sub-namespace 'alice.vouchers.special' you have to issue a RequestPrepareAnnounce object again, this time with
        parent set to 'alice.vouchers'. and the newPart being 'special'.</p>

    <p>After a year the root namespace expires. In order not to let this happen you need to send a provision namespace transaction for the root namespace
        within one month before it expires. The RequestPrepareAnnounce object is the same as if you were renting the namespace for the first time.
        The renewal of the root namespace also automatically renews any sub-namespace of that root namespace that the account already owns.
    </p>

    <h2>Creating mosaics</h2>

    <h3>Creating a mosaic definition</h3>

    <p>The basics of the NEM mosaic concept can be found in the chapter <a href="#mosaics">Mosaics</a>.<br>
        To define and create a mosaic type you need to issue a <a href="#mosaicDefinitionCreationTransaction">MosaicDefinitionCreationTransaction</a>.
        As usual this is done by sending a RequestPrepareAnnounce JSON object to NIS which in this case would look like this:
    </p>

        <pre><code class="JSON">
{
        "transaction":
        {
            "timeStamp": 9111526,
            "fee": 108000000,
            "type": 16385,
            "deadline": 9154726,
            "version": -1744830463,
            "signer": "cbda3edb771d42801a5c6ce0725f9374efade19a8933d6ac22ccfa50c777d0f9",
            "creationFee": 50000000000,
            "creationFeeSink": "53e140b5947f104cabc2d6fe8baedbc30ef9a0609c717d9613de593ec2a266d3",
            "mosaicDefinition": {
                "creator": "cbda3edb771d42801a5c6ce0725f9374efade19a8933d6ac22ccfa50c777d0f9",
                "description": "precious vouchers",
                "id": {
                    "namespaceId": "alice.vouchers",
                    "name": "Alice's gift vouchers"
                },
                "properties": [{
                    "name": "divisibility",
                    "value": "0"
                },{
                    "name": "initialSupply",
                    "value": "1000"
                },{
                    "name": "supplyMutable",
                    "value": "true"
                },{
                    "name": "transferable",
                    "value": "false"
                }
            ],
            "levy": {
                "type": 1,
                "recipient": "TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
                "mosaicId": {
                    "namespaceId": "nem",
                    "name": "xem"
                },
                "fee": 10
                }
            }
        },
        "privateKey": "00983bb01d05edecfaef55df9486c111abb6299c754a002069b1d0ef4537441bda"
}
        </code></pre>

    <p>With the above transaction a mosaic with id 'alice.vouchers * Alice's gift vouchers' is created within the namespace 'alice.vouchers'. The account must
        own that namespace in order to be able to create a mosaic in it. There is a high creation fee for creating mosaic definition in order to discourage
        squatting. As stated in the previous chapter, the fee is not transferred to the block harvester but to a special account whose public key is
        provided in the field 'creationFeeSink'.</p>

    <p>The mosaic has the following properties:
    <li>It is not divisible, i.e. the vouchers that the mosaic represents can only be transferred as a whole, not partially.</li>
    <li>There will be initially 1000 vouchers (mosaics of that type).</li>
    <li>The supply (the number of mosaics of that type) can be changed at a later point.</li>
    <li>The vouchers are not transferable among accounts. Only the creator of the mosaic can transfer vouchers to other accounts and once an account
        owns a voucher it can only be transferred back to the creator.
    </li>
    The definition also implies a levy with each transfer. The levy section states that there is an additional fee of 10 XEM for each transfer. That fee
    is send to the recipient with address TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH.<br>
    This levy part of the transaction is optional. If that part is ommited no additional fee arises from transferring the mosaics.
    </p>
    <p>Reasons for NIS now accepting the transactions are most likely:
    <li>The transaction signer does not own the namespace that is specified in the mosaic definition or the namespace has expired.</li>
    <li>A mosaic definition with the specified mosaic id already exists (see discussion below about altering mosaic definitions).</li>
    <li>The public key of the creation fee sink is invalid or the creation fee is too low.</li>
    <li>The mosaic id in the levy part of the transaction is unknown to NIS.</li>
    </p>

    <p>When the transaction gets included into a block and the block is executed, The creator will be credited the amount of mosaics stated in the
        'initialSupply' field (in the example 1000).</p>

    <h3>Altering a mosaic definition</h3>

    <p>There might be the need to alter a mosaic definition, either because you want to change the description or because you supplied faulty properties or
        faulty levy data. This is done simply by issuing another mosaic definition creation transaction as described above with the same mosaic id but
        different description/properties/levy. However there are some restriction when doing so:
    <li>The description can be changed at any point even if the creator does not own the entire supply.</li>
    <li>Properties and the levy data can <b>only</b> be changed if the creator owns every single mosaic of that type. This is necessary to prevent
        the creator from secretly introducing a levy or inflating the mosaic by increasing the supply.
    </li>
    Keep in mind that renewing the mosaic definition costs you 50000 XEM again, so it is worthwhile to double check the data before issuing the
    transaction.
    </p>

    <h3>Changing the mosaic supply</h3>

    <p>In case you created a mosaic definition with 'supplyMutable' set to true, you are able to change the mosaic supply. To do so, you must
        issue a <a href="#mosaicSupplyChangeTransaction">MosaicSupplyChangeTransaction</a>. This is done by sending a RequestPrepareAnnounce JSON object
        to NIS which in this case would look like this:
    </p>

        <pre><code class="JSON">
{
        "transaction":
        {
            "timeStamp": 9111526,
            "fee": 108000000,
            "type": 16386,
            "deadline": 9154726,
            "version": -1744830463,
            "signer": "d99e88c90da71a4b0d848454e59e296c9ef7a8f018f3eaa3a198dc460b6621a4",
            "supplyType": 1,
            "delta": 100,
            "mosaicId": {
                "namespaceId": "alice.vouchers",
                "name": "Alice's gift vouchers"
            }
        },
        "privateKey": "00983bb01d05edecfaef55df9486c111abb6299c754a002069b1d0ef4537441bda"
}
        </code></pre>

    <p>In the above example the supply for an existing mosaic with id 'alice.vouchers * Alice's gift vouchers' is changed. Specifically
    <li>the supplyType 1 means the supply is increased (a supply type of 2 means a supply decrease).</li>
    <li>the delta of 100 means that another 100 units are credited to the creators account.</li>
    </p>

    <p>Reasons for NIS now accepting the transactions are most likely:
    <li>The transaction signer is not the creator os the mosaic.</li>
    <li>The mosaic definition states that the supply is immutable.</li>
    <li>When attempting to increase the supply, the total supply must not exceed 9,000,000,000 mosaics.</li>
    <li>When attempting to decrease the supply, the creator must own the number of mosaics that he wants to delete.</li>
    </p>

    <p>After the transaction gets included into the block chain, the supply change is realized.</p>

    <h2>Creating a signed transaction</h2>

    <p>This chapter explains which data from the transactions you need to sign and what JSON object
        you to send to NIS.</p>

    <h3>Gathering data for the signature</h3>

    <p>To create a transaction signature you need to sign an array of bytes extracted from the transaction.
        Since there is more than one type of transaction the byte array will have a different structure for
        different types of transactions. Nevertheless the first part of the byte array has the same structure
        for every transaction.
        Note that:</p>

    <li>
        when the field denotes a number the endianess matters.
    </li>
    <li>
        the order in which the fields are concatenated matters.
    </li>

    <h4colored>Common transaction part of the byte array</h4colored>
    <li>
        <b>Transaction type:</b> 4 bytes (integer). The following types are supported:
        <ul>
            <li>0x0101 (transfer transaction)</li>
            <li>0x0801 (importance transfer transaction)</li>
            <li>0x1001 (multisig aggregate modification transfer transaction)</li>
            <li>0x1002 (multisig signature transaction)</li>
            <li>0x1004 (multisig transaction)</li>
            <li>0x2001 (provision namespace transaction)</li>
            <li>0x4001 (mosaic definition creation transaction)</li>
            <li>0x4002 (mosaic supply change transaction)</li>
            <b>example (importance transfer transaction): </b> 0x01, 0x08, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Version:</b> 4 bytes (integer). The following versions are supported:
        <ul>
            <p>
                For importance transfer transactions, multisig transactions, multisig signature transactions,
                provision namespace transactions, mosaic definition creation transactions and
                mosaic supply change transactions the version must be
            </p>
            <li>0x68 &lt;&lt; 24 + 1 (main network)</li>
            <li>0x60 &lt;&lt; 24 + 1 (mijin network)</li>
            <li>0x98 &lt;&lt; 24 + 1 (test network)</li>
            <b>Example (main network):</b> 0x01, 0x00, 0x00, 0x68
            <p></p>

            <p>
                For transfer transactions and multisig aggregate modification transactions the version must be
            </p>
            <li>0x68 &lt;&lt; 24 + 2 (main network)</li>
            <li>0x60 &lt;&lt; 24 + 2 (mijin network)</li>
            <li>0x98 &lt;&lt; 24 + 2 (test network)</li>
            <b>Example (main network):</b> 0x02, 0x00, 0x00, 0x68
        </ul>
    </li>
    <li>
        <b>Timestamp:</b> 4 bytes (integer).
        <ul>
            <b>Example (timestamp = 0x129623):</b> 0x23, 0x96, 0x12, 0x00
        </ul>
    </li>
    <li>
        <b>Length of public key byte array (always 32):</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x20, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Public key bytes of signer:</b> 32 bytes.
        <ul>
            <b>Example:</b> 0x6d, 0xa3, 0x76, 0x07, 0x13, 0x01, 0x9e, 0x26, 0xb1, 0x86, 0x24, 0x3a,
            0xb6, 0xec, 0xba, 0x9f, 0x70, 0x78, 0x4c, 0x59, 0x92, 0x3d, 0x68, 0x9a,
            0xb5, 0x4d, 0x4b, 0x2b, 0xf0, 0xe2, 0x0f, 0x5d
        </ul>
    </li>
    <li>
        <b>Fee (micro nem):</b> 8 bytes (long).
        <ul>
            <b>Example (12 nem):</b> 0x00, 0x1b, 0xb7, 0x00, 0x00, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Deadline:</b> 4 bytes (integer).
        <ul>
            <b>Example (deadline = 0x147824):</b> 0x24, 0x78, 0x14, 0x00
        </ul>
    </li>

    <h4colored>Transfer transaction part</h4colored>
    <li>
        <b>Length of recipient address (always 40):</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x28, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Recipient address:</b> 40 bytes (using UTF8 encoding).
        <ul>
            <b>Example ("NACCH2WPJYVQ3PLGMVZVRK5JI6POTJXXHLUG3P4J"):</b> 0x4e, 0x41, 0x43, 0x43, 0x48, 0x32, 0x57, 0x50,
            0x4a, 0x59, 0x56, 0x51, 0x33, 0x50, 0x4c, 0x47, 0x4d, 0x56, 0x5a, 0x56, 0x52, 0x4b, 0x35, 0x4a, 0x49, 0x36,
            0x50, 0x4f, 0x54, 0x4a, 0x58, 0x58, 0x48, 0x4c, 0x55, 0x47, 0x33, 0x50, 0x34, 0x4a
        </ul>
    </li>
    <li>
        <b>Amount (micro nem):</b> 8 bytes (long).
        <ul>
            <b>Example (1234 NEM):</b> 0x80, 0x58, 0x8d, 0x49, 0x00, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of message field:</b> 4 bytes (integer). Note: if the length is 0 then the following 2 fields do not apply.
        <ul>
            <b>Example:</b> 0x24, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Message type:</b> 4 bytes (integer). The following message types are supported.
        <ul>
            <li>0x01 (plain message)</li>
            <li>0x02 (secure, i.e. encrypted, message)</li>
            <b>Example:</b> 0x01, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of payload:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x05, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Payload:</b> UTF8 encoded string.
        <ul>
            <b>Example ("Hello"):</b> 0x48, 0x65, 0x6c, 0x6c, 0x6f
        </ul>
    </li>
    <p><b>Note:</b> the following part is optional and only available for version 2 transfer transactions that have an attachment.</p>
    <li>
        <b>Number of mosaics:</b> 4 bytes (integer).
        <ul>
            <b>Example (1 mosaic):</b> 0x01, 0x00, 0x00, 0x00
        </ul>
    </li>
    <p>The following part is repeated for every mosaic in the attachment.</p>
    <li>
        <b>Length of mosaic structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x1c, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of mosaic id structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x10, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of namespace id string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x03, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>namespace id string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("id9")</b> 0x69, 0x64, 0x39
        </ul>
    </li>
    <li>
        <b>Length of mosaic name string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x05, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Mosaic name string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("name9")</b> 0x6e, 0x61, 0x6d, 0x65, 0x39
        </ul>
    </li>
    <li>
        <b>Quantity:</b> 8 bytes (long).
        <ul>
            <b>Example: (24)</b> 0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
        </ul>
    </li>


    <h4colored>Importance transfer transaction part</h4colored>
    <li>
        <b>Importance transfer mode:</b> 4 bytes (integer). The following modes are supported:
        <ul>
            <li>0x01 (Activate)</li>
            <li>0x02 (Deactivate)</li>
            <b>Example (mode Activate):</b> 0x01, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of remote account public key byte array (always 32):</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x20, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Public key bytes of remote account:</b> 32 bytes.
        <ul>
            <b>Example:</b> 0x6d, 0xa3, 0x76, 0x07, 0x13, 0x01, 0x9e, 0x26, 0xb1, 0x86, 0x24, 0x3a,
            0xb6, 0xec, 0xba, 0x9f, 0x70, 0x78, 0x4c, 0x59, 0x92, 0x3d, 0x68, 0x9a,
            0xb5, 0x4d, 0x4b, 0x2b, 0xf0, 0xe2, 0x0f, 0x5d
        </ul>
    </li>

    <h4colored>Aggregate modification transaction part</h4colored>
    <li>
        <b>Number of cosignatory modifications:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x03, 0x00, 0x00, 0x00
        </ul>
    </li>
    <p>The following part is repeated for every cosignatory modification</p>
    <li>
        <b>Length of cosignatory modification structure:</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x28, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Modification type:</b> 4 bytes (integer). The following modification types are supported:
        <ul>
            <li>0x01 (Add cosignatory)</li>
            <li>0x02 (Delete cosignatory)</li>
            <b>Example (Delete):</b> 0x02, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of cosignatory's public key byte array (always 32):</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x20, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Public key bytes of cosignatory:</b> 32 bytes.
        <ul>
            <b>Example:</b> 0x6d, 0xa3, 0x76, 0x07, 0x13, 0x01, 0x9e, 0x26, 0xb1, 0x86, 0x24, 0x3a,
            0xb6, 0xec, 0xba, 0x9f, 0x70, 0x78, 0x4c, 0x59, 0x92, 0x3d, 0x68, 0x9a,
            0xb5, 0x4d, 0x4b, 0x2b, 0xf0, 0xe2, 0x0f, 0x5d
        </ul>
    </li>
    <p>The following part describes the minimum cosignatories modification. The part is optional.
        Version 1 aggregate modification transactions should omit this part.
        Version 2 aggregate modification transactions with no minimum cosignatories modification should only write
        the length field with value 0x00, 0x00, 0x00, 0x00.</p>
    <li>
        <b>Length of minimum cosignatories modification structure:</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x04, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Relative change:</b> 4 bytes (integer).
        <ul>
            <b>Example (relative change of 2):</b> 0x02, 0x00, 0x00, 0x00
        </ul>
    </li>

    <h4colored>Multisig signature transaction part</h4colored>
    <li>
        <b>Length of hash object (hash of the corresponding multisig transaction):</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x24, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of hash:</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x20, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>SHA3 hash bytes:</b> 32 bytes.
        <ul>
            <b>Example:</b> 0x7d, 0x76, 0xfe, 0x26, 0xc4, 0x54, 0x61, 0xf7, 0x4b, 0xcb, 0x76, 0xac,
            0xae, 0xb0, 0x17, 0x39, 0x9e, 0xbe, 0x50, 0xaa, 0x71, 0x46, 0xe2, 0x62, 0x57, 0x39,
            0x5f,0xbb,0xc0,0x25,0xac,0xb7
        </ul>
    </li>
    <li>
        <b>Length of address of the corresponding multisig account (always 40):</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x28, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Multisig account address:</b> 40 bytes (using UTF8 encoding).
        <ul>
            <b>Example ("NACCH2WPJYVQ3PLGMVZVRK5JI6POTJXXHLUG3P4J"):</b> 0x4e, 0x41, 0x43, 0x43, 0x48, 0x32, 0x57, 0x50,
            0x4a, 0x59, 0x56, 0x51, 0x33, 0x50, 0x4c, 0x47, 0x4d, 0x56, 0x5a, 0x56, 0x52, 0x4b, 0x35, 0x4a, 0x49, 0x36,
            0x50, 0x4f, 0x54, 0x4a, 0x58, 0x58, 0x48, 0x4c, 0x55, 0x47, 0x33, 0x50, 0x34, 0x4a
        </ul>
    </li>

    <h4colored>Multisig transaction part</h4colored>
    <li>
        <b>Length of inner transaction object. This can be a transfer, an importance transfer or an aggregate modification transaction.</b>
        <ul>
            <b>Example:</b> 0x74, 0x00, 0x00, 0x00
        </ul>
    </li>
    <p>What follows here is the inner transaction object. The structure is one of the structures
        described above transactions (excluding signature transactions).</p>

    <h4colored>Provision namespace transaction part</h4colored>
    <li>
        <b>Length of rental fee sink's Encoded Address (always 40):</b> 4 bytes (integer).
        <ul>          
            <b>Always:</b> 0x28, 0x00, 0x00, 0x00           
        </ul>
    </li>
    <li>
        <b>Address bytes of rental fee sink:</b> 40 bytes.
        <ul>
            <b>Network dependant sink address (i.e. TAMESPACEWH4MKFMBCVFERDPOOP4FK7MTDJEYP35):</b>
                0x54, 0x41, 0x4d, 0x45, 0x53, 0x50, 0x41, 0x43, 0x45, 0x57, 0x48, 0x34, 0x4d, 0x4b, 0x46, 0x4d, 0x42, 0x43, 0x56, 0x46,
                0x45, 0x52, 0x44, 0x50, 0x4f, 0x4f, 0x50, 0x34, 0x46, 0x4b, 0x37, 0x4d, 0x54, 0x44, 0x4a, 0x45, 0x59, 0x50, 0x33, 0x35
        </ul>
    </li>
    <li>
        <b>Rental fee (Root always: 5000000000, Sub always: 200000000) for namespace:</b> 8 bytes (long).
       	<ul>
            <li><b>Root always:</b> 0x00, 0xf2, 0x05, 0x2a, 0x01, 0x00, 0x00, 0x00</li>
            <li><b>Sub always:</b> 0x00, 0xc2, 0xeb, 0x0b, 0x00, 0x00, 0x00, 0x00</li>
        </ul>
    </li>
    <li>
        <b>Length of new part string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x03, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>New part string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("bar")</b> 0x62, 0x61, 0x72
        </ul>
    </li>
    <li>
        <b>Length of parent string:</b> 4 bytes (integer).
        <b>Note:</b> If the parent should be null (provisioning a root namespace),
        then this field has to be set to 0xff, 0xff, 0xff, 0xff and the next field is omitted!
        <ul>
            <b>Example:</b> 0x03, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Parent string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("foo")</b> 0x66, 0x6f, 0x6f
        </ul>
    </li>

    <h4colored>Mosaic definition creation transaction part</h4colored>
    <li>
        <b>Length of mosaic definition structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x29, 0x01, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of creator's public key byte array (always 32):</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x20, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Public key bytes of creator:</b> 32 bytes.
        <ul>
            <b>Example:</b> 0x8f, 0xcd, 0xce, 0xd0, 0x85, 0xcb, 0x58, 0xe3, 0x62, 0x6e,
            0x7e, 0xfb, 0xab, 0xc7, 0xa6, 0x3d, 0x87, 0x3e, 0x7d, 0xf5, 0xb6, 0x24,
            0x6c, 0x65, 0x9b, 0x2c, 0x10, 0x8f, 0x90, 0xab, 0x44, 0xf2
        </ul>
    </li>
    <li>
        <b>Length of mosaic id structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x2b, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of namespace id string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x0e, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Namespace id string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("alice.vouchers")</b> 0x61, 0x6c, 0x69, 0x63, 0x65, 0x2e, 0x76, 0x6f, 0x75, 0x63, 0x68, 0x65, 0x72, 0x73
        </ul>
    </li>
    <li>
        <b>Length of mosaic name string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x15, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Mosaic name string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("Alice's gift vouchers")</b> 0x41, 0x6c, 0x69, 0x63, 0x65, 0x27, 0x73, 0x20, 0x67,
            0x69, 0x66, 0x74, 0x20, 0x76, 0x6f, 0x75, 0x63, 0x68, 0x65, 0x72, 0x73
        </ul>
    </li>
    <li>
        <b>Length of description string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x11, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Description string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("precious vouchers")</b> 0x70, 0x72, 0x65, 0x63, 0x69, 0x6f, 0x75, 0x73, 0x20, 0x76, 0x6f, 0x75, 0x63, 0x68, 0x65, 0x72, 0x73
        </ul>
    </li>
    <li>
        <b>Number of properties:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x02, 0x00, 0x00, 0x00
        </ul>
    </li>
    <p>The following 5 fields are repeated for every property. <b>Note:</b> The property values are always strings</p>
    <li>
        <b>Length of the property structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x15, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of the property name:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x0c, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Property name:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("divisibility")</b> 0x64, 0x69, 0x76, 0x69, 0x73, 0x69, 0x62, 0x69, 0x6c, 0x69, 0x74, 0x79
        </ul>
    </li>
    <li>
        <b>Length of the property value:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x01, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Property value:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("3")</b> 0x33
        </ul>
    </li>
    <li>
        <b>Length of the property structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x16, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of the property name:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x0d, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Property name:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("initialSupply")</b> 0x69, 0x6e, 0x69, 0x74, 0x69, 0x61, 0x6c, 0x53, 0x75, 0x70, 0x70, 0x6c, 0x79
        </ul>
    </li>
    <li>
        <b>Length of the property value:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x01, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Property value:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("0")</b> 0x30
        </ul>
    </li>
    <li>
        <b>Length of the property structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x1a, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of the property name:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x0d, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Property name:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("supplyMutable")</b> 0x73, 0x75, 0x70, 0x70, 0x6c, 0x79, 0x4d, 0x75, 0x74, 0x61, 0x62, 0x6c, 0x65
        </ul>
    </li>
    <li>
        <b>Length of the property value:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x05, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Property value:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("false")</b> 0x66, 0x61, 0x6c, 0x73, 0x65
        </ul>
    </li>
    <li>
        <b>Length of the property structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x18, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of the property name:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x0c, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Property name:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("transferable")</b> 0x74, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x61, 0x62, 0x6c, 0x65
        </ul>
    </li>
    <li>
        <b>Length of the property value:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x04, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Property value:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("true")</b> 0x74, 0x72, 0x75, 0x65
        </ul>
    </li>
    <p><b>Note:</b> The following levy object is optional.
        Set length field to 0 if the mosaic definition has no levy and omit all subsequent fields up to the comment
        "The levy structure ends here.".</p>
    <li>
        <b>Length of levy structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x4c, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Fee type:</b> 4 bytes (integer). The following fee types are supported.
        <ul>
            <li>0x01 (absolute fee)</li>
            <li>0x02 (percentile fee)</li>
            <b>Example:</b> 0x01, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of recipient address field (always 40):</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x28, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Recipient address:</b> 40 bytes (using UTF8 encoding).
        <ul>
            <b>Example ("NACCH2WPJYVQ3PLGMVZVRK5JI6POTJXXHLUG3P4J"):</b> 0x4e, 0x41, 0x43, 0x43, 0x48, 0x32, 0x57, 0x50,
            0x4a, 0x59, 0x56, 0x51, 0x33, 0x50, 0x4c, 0x47, 0x4d, 0x56, 0x5a, 0x56, 0x52, 0x4b, 0x35, 0x4a, 0x49, 0x36,
            0x50, 0x4f, 0x54, 0x4a, 0x58, 0x58, 0x48, 0x4c, 0x55, 0x47, 0x33, 0x50, 0x34, 0x4a
        </ul>
    </li>
    <li>
        <b>Length of mosaic id structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x10, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of namespace id string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x03, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Namespace id string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("id2")</b> 0x69, 0x64, 0x32
        </ul>
    </li>
    <li>
        <b>Length of mosaic name string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x05, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Mosaic name string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("name2")</b> 0x6e, 0x61, 0x6d, 0x65, 0x32
        </ul>
    </li>
    <li>
        <b>Fee quantity:</b> 8 bytes (long).
        <ul>
            <b>Example: (123)</b> 0x7b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
        </ul>
    </li>
    <p>The levy structure ends here.</p>
    <li>
        <b>Length of creation fee sink's encoded address byte array (always 40):</b> 4 bytes (integer).
        <ul>
            <b>Always:</b> 0x28, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Address key bytes of creation fee sink:</b> 40 bytes.
        <ul>
            <b>Network dependant sink address (i.e. TBMOSAICOD4F54EE5CDMR23CCBGOAM2XSJBR5OLC):</b>
                0x54, 0x42, 0x4d, 0x4f, 0x53, 0x41, 0x49, 0x43, 0x4f, 0x44, 0x34, 0x46, 0x35, 0x34, 0x45, 0x45, 0x35, 0x43, 0x44, 0x4d,
                0x52, 0x32, 0x33, 0x43, 0x43, 0x42, 0x47, 0x4f, 0x41, 0x4d, 0x32, 0x58, 0x53, 0x4a, 0x42, 0x52, 0x35, 0x4f, 0x4c, 0x43
        </ul>
    </li>
    <li>
        <b>Fee quantity:</b> 8 bytes (long).
        <ul>
            <b>Always: (5000000000)</b> 0x00, 0xf2, 0x05, 0x2a, 0x01, 0x00, 0x00, 0x00
        </ul>
    </li>

    <h4colored>Mosaic supply change transaction part</h4colored>
    <li>
        <b>Length of mosaic id structure:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x12, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Length of namespace id string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x07, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Namespace id string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("foo.bar")</b> 0x66, 0x6f, 0x6f, 0x2e, 0x62, 0x61, 0x72
        </ul>
    </li>
    <li>
        <b>Length of mosaic name string:</b> 4 bytes (integer).
        <ul>
            <b>Example:</b> 0x03, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Mosaic name string:</b> UTF8 encoded string.
        <ul>
            <b>Example: ("baz")</b> 0x62, 0x61, 0x7a
        </ul>
    </li>
    <li>
        <b>Supply type:</b> 4 bytes (integer). The following supply types are supported.
        <ul>
            <li>0x01 (increase supply)</li>
            <li>0x02 (decrease supply)</li>
            <b>Example:</b> 0x01, 0x00, 0x00, 0x00
        </ul>
    </li>
    <li>
        <b>Delta (change in supply):</b> 8 bytes (long).
        <ul>
            <b>Example: (100)</b> 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
        </ul>
    </li>

    <h4colored>Building the byte array</h4colored>
    <p>To build the final byte array that needs to be signed, simply concatenate the common part for a transaction and the type specific part.
        For example if you want to build the byte array for a transfer transaction you have as common something that looks like</p>

    <p>0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x6f, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x68, 0x32, 0x03, 0xb4,
        0x55, 0x09, 0x0e, 0x2f, 0xfe, 0xd6, 0x48, 0x53, 0x6c, 0x99, 0x01, 0x4d, 0x1c, 0xa9, 0x2c, 0x10, 0x47, 0xaf, 0xbc, 0xae,
        0x58, 0x05, 0x7b, 0xb6, 0xa6, 0x98, 0xc8, 0x0b, 0x80, 0x84, 0x1e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00</p>

    <p>and a transfer transaction specific part</p>

    <p>0x28, 0x00, 0x00, 0x00, 0x54, 0x41, 0x49, 0x34, 0x35, 0x32, 0x53, 0x37, 0x44, 0x4c, 0x36, 0x57, 0x48, 0x57, 0x54, 0x5a,
        0x5a, 0x32, 0x57, 0x33, 0x44, 0x49, 0x4d, 0x34, 0x32, 0x36, 0x58, 0x57, 0x49, 0x4a, 0x4b, 0x4c, 0x55, 0x4e, 0x58, 0x4e,
        0x4b, 0x54, 0x37, 0x4c, 0x40, 0x2f, 0x07, 0x2f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00</p>

    <p>which gives you the final array</p>

    <p>0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x6f, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x68, 0x32, 0x03, 0xb4,
        0x55, 0x09, 0x0e, 0x2f, 0xfe, 0xd6, 0x48, 0x53, 0x6c, 0x99, 0x01, 0x4d, 0x1c, 0xa9, 0x2c, 0x10, 0x47, 0xaf, 0xbc, 0xae,
        0x58, 0x05, 0x7b, 0xb6, 0xa6, 0x98, 0xc8, 0x0b, 0x80, 0x84, 0x1e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
        0x28, 0x00, 0x00, 0x00, 0x54, 0x41, 0x49, 0x34, 0x35, 0x32, 0x53, 0x37, 0x44, 0x4c, 0x36, 0x57, 0x48, 0x57, 0x54, 0x5a,
        0x5a, 0x32, 0x57, 0x33, 0x44, 0x49, 0x4d, 0x34, 0x32, 0x36, 0x58, 0x57, 0x49, 0x4a, 0x4b, 0x4c, 0x55, 0x4e, 0x58, 0x4e,
        0x4b, 0x54, 0x37, 0x4c, 0x40, 0x2f, 0x07, 0x2f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00</p>

    <p>Signing this array will give you the 64 byte long signature.</p>

    <h4colored>Calculating the hash of a transaction</h4colored>
    <p>NIS uses the SHA3-256 hash function. To create a hash of a transaction you need to hash the byte array of the transaction.
        See the section above to learn how to build the byte array from a transaction.</p>

    <h3>Sending the data to NIS</h3>

    <p>After preparing the data as described in the last section you can send the array and the corresponding signature via a
        RequestAnnounce request</p>

    <api post>/transaction/announce</api>
    <desc>
        <p class=NemNoSpacing>Creates and broadcasts a transaction. The private key is not involved.</p>
    </desc>

    <h4>Parameter:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>requestAnnounce</p>
            </td>
            <td>
                <p class=NemNoSpacing>A RequestAnnounce JSON object as described in
                    <appa>RequestAnnounce</appa>
                    .
                </p>
            </td>
        </tr>
    </table>

    <h4>Example:</h4>

    <p class=NemNoSpacing>Request cannot be performed in a browser.</p>

    <h4>Example of returned JSON <a href="#nemAnnounceResult">NemAnnounceResult</a> object:</h4>

    <resp>
{
        "type":1,
        "code":1,
        "message":"SUCCESS",
        "transactionHash": {
        "data":"c1786437336da077cd572a27710c40c378610e8d33880bcb7bdb0a42e3d35586"
        },
        "innerTransactionHash": {
        "data":"cc317a7674d56352b4c711096a7594bd11908bf518293a191fc2faa12eac0fbb"
        }
}
    </resp>

    <h4>Possible Errors:</h4>

    <p>The possible erros are described in chapter 6.1.</p>

    <h2>Transaction fees</h2>

    <p>In order for the harvesters to have an incentive to run a node that is harvesting blocks,
        users have to pay a fee for every transaction that is going to be included in a block chain.</p>

    <p>Different transaction types have different fees. In order to get a transaction
        validated by a NIS, the fee provided must be at least the minimum fee.</p>

    <p><b>Note:</b> Depending on the transaction type there could be additional fees due to the action
        during transaction execution (e.g. renting a namespace)</p>

    <p>The following chart summarizes the minimum fees for each transaction type.
        All calculation are done with rounded amounts of XEM (i.e. micro XEM are ignored):</p>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>Transfer transaction</p>
            </td>
            <td>
                <p>The fee is the sum of the fee for transferring an amount of
                    XEM and the fee for appending a message to the transaction.</p>

				<ol>
				<li>Fees for transferring XEM to another account:<br>
                    1 xem per 10,000 xem transferred, capped at 25 xem<br>
                    Example:<br>
                    4 xem fee for a 45,000 xem transfer, 25 xem fee for a 500,000 xem transfer.</li>

                <li>Fees for appending a message to a transaction:<br>
                    1 xem per commenced 32 message bytes (messageLength / 32 + 1).<br>
                    Example:<br>
                    The unencrypted message „The New Economy Movement will change the world!!!” has a length 49
                    characters and thus will cost 2 xem fee.</li>

                <li>Fees for transferring a mosaic to another account:
                    <ol>
                        <li>mosaics with divisibility of 0 and a maximum supply of 10,000 are called small business mosaics.<br>
	                    1 xem fee for any transfer of a small business mosaic.</li>
                        <li> For each mosaic that is transferred the fee is calculated the following way:
                        given a mosaic with initial supply s, divisibility d and quantity q, the XEM equivalent is (round to the next smaller integer)<br>
                        xemEquivalent = (8,999,999,999 * q) / (s * 10^d) <br>
                        To take into account the total quantities for different mosaics, an adjustment term is calculated.<br>
                        For a mosaic called m calculate<br>
						<ol>
							<li> maxMosaicQuantity = 9,000,000,000,000,000 </li>
							<li> totalMosaicQuantity = mosaic m supply * 10 ^ (mosaic m divisibility) </li>
							<li> supplyRelatedAdjustment = floor(0.8 * ln(maxMosaicQuantity  / totalMosaicQuantity) </li>
							<li> Then the fee is calculated as<br>
							fee = max(1L, xemFee - supplyRelatedAdjustment)</li>
						</ol>
                        Example:<br>
                        Suppose you have a mosaic with 9,000,000 supply and divisibility of 3.
						<ol>
							<li> totalMosaicQuantity  = 9,000,000 * 1,000 = 9,000,000,000 </li>
							<li> supplyRelatedAdjustment = floor(0.8 * ln(9,000,000,000,000,000 / 9,000,000,000)) = floor(11.052) = 11 </li>
							<li> transferring 150 such mosaics (i.e. a quantity of 150,000 smallest units) has<br>
	                        xemEquivalent = (8,999,999,999 * 150,000) / (9,000,000 * 10^3) = 149,999<br>
	                        xemFee = 14 xem</li>
	                        <li> So the transction will have the following fee:<br>
	                        fee = 14 xem - 11 xem = 3 xem</li>
						</ol>
                        </li>
                    </ol>
                </li>
				</ol>
             </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>Importance transfer transaction</p>
            </td>
            <td>
                <p>6 XEM</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>Aggregate modification transaction</p>
            </td>
            <td>
                <p>10 + 6 * number of modifications + 6 (if a min cosignatory change is involved)<br>
                    Example:<br>
                    Adding 3 cosignatories to an account without changing the min cosignatories will cost<br>
                    10 + 6 * 3 = 28 XEM.<br>
                    Adding 3 cosignatories to an account and changing the min cosignatories will cost<br>
                    10 + 6 * 3 + 6 = 34 XEM.<br>
                </p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>Multisig transaction</p>
            </td>
            <td>
                <p>6 XEM</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>Multisig signature transaction</p>
            </td>
            <td>
                <p>6 XEM</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>Provision namespace transaction</p>
            </td>
            <td>
                <p>20 XEM</p>
                <p>plus:</p>
                <p>Fee for root namespace provisioning: 5000 XEM</p>
                <p>Fee for sub-namespace provisioning: 200 XEM</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>Mosaic definition creation transaction</p>
            </td>
            <td>
                <p>20 XEM</p>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>Mosaic supply change transaction</p>
            </td>
            <td>
                <p>20 XEM</p>
            </td>
        </tr>
    </table>

    <h1>Requests for additional information from NIS</h1>

    <p>Several requests supply additional information about the internal status of NIS.</p>

    <div class="warning">Those requests may get dropped in future versions of NIS
        without further notice, you should not rely on their existence.
    </div>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Monitoring the network time</h2>

    <api get>/debug/time-synchronization</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of time synchronization
            results as described in
            <appa>TimeSynchronizationResult</appa>
            . You can monitor the change in network time with this information.
        </p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/debug/time-synchronization">http://127.0.0.1:7890/debug/time-synchronization</a></p>

    <h4>Example of returned array of JSON <a href="#timeSynchronizationResult">TimeSynchronizationResult</a> objects:</h4>

    <resp>
{
       "data": [
       {
              "dateTime": "2014-11-19 19:23:04",
              "currentTimeOffset": 1747,
              "change": 57
       },
       {
              "dateTime": "2014-11-19 19:24:17",
              "currentTimeOffset": 1776,
              "change": 29
       },
       {
              "dateTime": "2014-11-19 19:25:18",
              "currentTimeOffset": 1729,
              "change": -47
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Monitoring incoming and outgoing calls</h2>

    <!-- ---- ---- ---- ---- ---- ---- -->
    <api get>/debug/connections/incoming</api>


    <desc>
        <p class=NemNoSpacing>Gets an audit collection of incoming
            calls as described in
            <appa>AuditCollection</appa>
            . You can monitor the
            outstanding and recent incoming requests with this information.
        </p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/debug/connections/incoming">http://127.0.0.1:7890/debug/connections/incoming</a></p>

    <h4>Example of returned JSON <a href="#auditCollection">AuditCollection</a> object:</h4>

    <resp>
{
       "outstanding": [
       {
              "path": "/debug/connections/incoming",
              "start-time": 9317306,
              "host": "127.0.0.1",
              "elapsed-time": 0,
              "id": 4070
       }],
       "most-recent": [
       {
              "path": "/debug/connections/incoming",
              "start-time": 9317306,
              "host": "127.0.0.1",
              "elapsed-time": 0,
              "id": 4070
       },
       {
              "path": "/chain/score",
              "start-time": 9317303,
              "host": "95.16.203.168",
              "elapsed-time": 3,
              "id": 4069
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <!-- ---- ---- ---- ---- ---- ---- -->
    <api get>/debug/connections/outgoing</api>


    <desc>
        <p class=NemNoSpacing>Gets an audit collection of outgoing
            calls as described in
            <appa>AuditCollection</appa>
            . You can monitor the
            outstanding and recent outgoing requests with this information.
        </p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/debug/connections/outgoing">http://127.0.0.1:7890/debug/connections/outgoing</a></p>

    <h4>Example of returned JSON <a href="#auditCollection">AuditCollection</a> object:</h4>

    <resp>
{
       "outstanding": [
       {
              "path": "/chain/blocks-after",
              "start-time": 9317511,
              "host": "88.12.55.125",
              "elapsed-time": 6,
              "id": 6452
       }],
       "most-recent": [
       {
              "path": "/chain/blocks-after",
              "start-time": 9317511,
              "host": "88.12.55.125",
              "elapsed-time": 6,
              "id": 6452
       },
       {
              "path": "/chain/hashes-from",
              "start-time": 9317511,
              "host": "88.12.55.125",
              "elapsed-time": 6,
              "id": 6451
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>

    <!-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -->
    <h2>Monitoring timers</h2>

    <api get>/debug/connections/timers</api>


    <desc>
        <p class=NemNoSpacing>Gets an array of task monitor structures
            as described in
            <appa>NemAsyncTimerVisitor</appa>
            . You can monitor
            the statistics for periodic tasks with this information.
        </p>
    </desc>

    <h4>No parameter:</h4>

    <h4>Example:</h4>

    <p><a href="http://127.0.0.1:7890/debug/timers">http://127.0.0.1:7890/debug/timers</a></p>

    <h4>Example of returned array of JSON <a href="#nemAsyncTimerVisitor">NemAsyncTimerVisitor</a> objects:</h4>

    <resp>
{
       "data": [
       {
              "last-delay-time": 3000,
              "executions": 1024,
              "failures": 0,
              "successes": 1024,
              "last-operation-start-time": 9317695,
              "is-executing": 0,
              "name": "FORAGING",
              "average-operation-time": 0,
              "last-operation-time": 0
       },
       {
              "last-delay-time": 74181,
              "executions": 71,
              "failures": 0,
              "successes": 71,
              "last-operation-start-time": 9317654,
              "is-executing": 0,
              "name": "REFRESH",
              "average-operation-time": 6,
              "last-operation-time": 7
       }]
}
    </resp>

    <h4>Possible Errors:</h4>

    <p class=NemNoSpacing>None.</p>


    <h1>Appendix A: Description of the JSON Structures</h1>

    <h2>AccountHistoricalDataViewModel</h2>
    <desc>
        <p class=NemNoSpacing>Nodes can support a feature for retrieving historical data of accounts.
            If a node supports this feature, it will return an array of AccountHistoricalDataViewModel objects.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
        "height": 8976,
        "address": "NALICELGU3IVY4DPJKHYLSSVYFFWYS5QPLYEZDJJ",
        "balance": 80670000000,
        "vestedBalance": 13949175142,
        "unvestedBalance": 66720824858,
        "importance": 0.00008166760846617221,
        "pageRank": 0.0006944567083595363
}
    </resp>

    <fields>
        <f name="height">The height for which the data is valid.</f>
        <f name="address">The address of the account.</f>
        <f name="balance">The balance of the account.</f>
        <f name="vestedBalance">The vested part of the balance.</f>
        <f name="unvestedBalance">The unvested part of the balance.</f>
        <f name="importance">The importance of the account.</f>
        <f name="pageRank">The page rank part of the importance.</f>
    </fields>

    <h2>AccountImportanceViewModel</h2>

    <desc>
        <p class=NemNoSpacing>Each account is assigned an importance
            in the NEM network. The ability of an account to generate new blocks is
            proportional to its importance. The importance is a number between 0 and 1.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "address": "TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS"
       "importance":
       {
           "isSet": 1,
           "score": 0.0011561555164258449,
           "ev": 0.004367936531009263,
           "height": 38413
       }
}
    </resp>

    <fields>
        <f name="address">The address of the account.</f>
        <f name="importance">Substructure that describes the importance of the account.</f>
        <f name="isSet">Indicates if the fields &quot;score&quot;, &quot;ev&quot; and &quot;height&quot; are available.isSet can have the values 0 or 1. In case
            isSet is 0 the fields are not available.
        </f>
        <f name="score">The importance of the account. The importance ranges between 0 and 1.</f>
        <f name="ev">The page rank portion of the importance. The page rank ranges between 0 and 1.</f>
        <f name="height">The height at which the importance calculation was performed.</f>
    </fields>

    <h2>AccountInfo</h2>

    <desc>
        <p class=NemNoSpacing>The account structure describes basic information for an account.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "address": "TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS",
       "balance": 124446551689680,
       "vestedBalance": 1041345514976241,
       "importance": 0.010263666447108395,
       "publicKey": "a11a1a6c17a24252e674d151713cdf51991ad101751e4af02a20c61b59f1fe1a",
       "label": null,
       "harvestedBlocks": 645
}
    </resp>

    <h4>Description of the fields:</h4>

    <fields>
        <f name="address">The address of the account.</f>
        <f name="balance">The balance of the account in micro NEM.</f>
        <f name="vestedBalance">The vested part of the balance of the account in micro NEM.</f>
        <f name="importance">The importance of the account.</f>
        <f name="publicKey">The public key of the account.</f>
        <f name="label">The label of the account (not used, always null).</f>
        <f name="harvestedBlocks">The number blocks that the account already harvested.</f>
    </fields>

    <h2>AccountMetaData</h2>

    <desc>
        <p class=NemNoSpacing>The account meta data describes
            additional information for the account. See <a href="#account-related-requests">Account related requests</a> for details.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "status": "LOCKED",
       "remoteStatus": "ACTIVE",
        "cosignatoryOf" : [
            &lt;AccountInfo&gt;,
            &lt;AccountInfo&gt;
        ],
        "cosignatories" : [
            &lt;AccountInfo&gt;,
            &lt;AccountInfo&gt;
        ]
}
    </resp>

    <h4>Description of the fields:</h4>

    <table class=NemTableGrid>
        <tr>
            <td>
                <p class=JSON>status</p>
            </td>
            <td>
                <p>The harvesting status of a queried account.</p>

                <p>The harvesting status can be one of the following values:</p>
                <vals>
                    &quot;UNKNOWN&quot;: The harvesting status of the account is not known.
                    &quot;LOCKED&quot;: The account is not harvesting.
                    &quot;UNLOCKED&quot;: The account is harvesting.
                </vals>
            </td>
        </tr>
        <tr>
            <td>
                <p class=JSON>remoteStatus</p>
            </td>
            <td>
                <p>The status of remote harvesting of a queried account.</p>

                <p>The remote harvesting status can be one of the following values:</p>
                <vals>
                    &quot;REMOTE&quot;: The account is a remote account and therefore remoteStatus is not applicable for it.
                    &quot;ACTIVATING&quot;: The account has activated remote harvesting but it is not yet active.
                    &quot;ACTIVE&quot;: The account has activated remote harvesting and remote harvesting is active.
                    &quot;DEACTIVATING&quot;: The account has deactivated remote harvesting but remote harvesting is still active.
                    &quot;INACTIVE&quot;: The account has inactive remote harvesting, or it has deactivated remote harvesting and deactivation is operational.
                </vals>
            </td>
        </tr>
        <tr>
            <td><p class="JSON">cosignatoryOf</p></td>
            <td>
                <p>JSON array of AccountInfo structures. The account is cosignatory for each of the accounts in the array.</p>
            </td>
        </tr>
        <tr>
            <td><p class="JSON">cosignatories</p></td>
            <td>
                <p>JSON array of AccountInfo structures. The array holds all accounts that are a cosignatory for this account.</p>
            </td>
        </tr>
    </table>

    <h2>AccountMetaDataPair</h2>

    <desc>
        <p class=NemNoSpacing>The account meta data pair includes
            durable information for an account and additional information about its state.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
    "account":
        &lt;AccountInfo&gt;,
    "meta":
        &lt;AccountMetaData&gt;
}
    </resp>

    <fields>
        <f name="account">Contains the account object.</f>
        <f name="&lt;AccountInfo&gt;">The account object as described in <a href="#accountInfo">AccountInfo</a>.</f>
        <f name="meta">Contains the account meta data object.</f>
        <f name="&lt;AccountMetaData&gt;">The account meta data object as described in <a href="#accountMetaData">AccountMetaData</a>.</f>
    </fields>

    <h2>AccountPrivateKeyTransactionsPage</h2>

    <desc>
        <p>The account private key transactions page contains data that NIS needs to
            retrieve a set of transactions from the database. The data includes the private
            key of the account for which transactions are retrieved. Use requests that use
            this structure only when NIS is running locally.</p>

        <p>The fields "hash" and "id" are optional.</p>
    </desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
    "value": "68e4f79f886927de698df4f857de2aada41ccca6617e56bb0d61623b35b08cc0",
    "hash": "44e4968e5aa35fe182d4def5958e23cf941c4bf809364afb4431ebbf6a18c039",
    "id": "12345"
}
    </resp>

    <fields>
        <f name="value">The private key as hexadecimal string.</f>
        <f name="hash">The optional hash value.</f>
        <f name="id">The optional transaction id.</f>
    </fields>

    <h2>ApplicationMetaData</h2>

    <desc>
        <p class=NemNoSpacing>The application meta data object
            supplies additional information about the application running on a node.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "currentTime": 9189086,
       "application": "NEM Infrastructure Server",
       "startTime": 9060202,
       "version": "0.4.30-BETA",
       "signer": "CN=NEM Community,OU=Development Team,O=NEM,L=Internet,ST=web,C=WD"
}
    </resp>

    <fields>
        <f name="currentTime">The current network time, i.e. the number of seconds that have elapsed since the creation of the nemesis block.</f>
        <f name="application">The name of the application running on the node.</f>
        <f name="startTime">The network time when the application was started.</f>
        <f name="version">The application version.</f>
        <f name="signer">The signer of the certificate used by the application.</f>
    </fields>

    <h2>AuditCollection</h2>

    <desc>
        <p class=NemNoSpacing>An audit collection consists of two
            arrays, containing information about incoming requests from other nodes. The
            first array contains information about outstanding (i.e. not yet processed
            requests) and the second array contains information about the most recent
            requests. The audit collection is for debug purposes.</p>
    </desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
       "outstanding": [{
              "path": "/chain/score",
              "start-time": 9020618,
              "host": "86.124.91.183",
              "elapsed-time": 5,
              "id": 797725
       }],
       "most-recent": [{
              "path": "/push/transaction",
              "start-time": 9020621,
              "host": "hachi.nem.ninja",
              "elapsed-time": 2,
              id": 797750
       }]
}
    </resp>

    <fields>
        <f name="path">The relative URL path.</f>
        <f name="start-time">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="host">The host which initiated the request.</f>
        <f name="elapsed-time">The time in seconds that has elapsed since the request was received.</f>
        <f name="id">The unique id of the request.</f>
    </fields>

    <h2>Block</h2>

    <desc>
        <p class=NemNoSpacing>A block is the structure that contains
            the transaction information. A block can contain up to 120 transactions. Blocks
            are generated and signed by accounts and are the instrument by which
            information is spread in the network.</p>
    </desc>

    <h4>JSON structure by example (main network):</h4>

    <resp>
{
       "timeStamp": 9022656,
       "signature": "256ebcfa4f92e2881963359c51095a390b9f4d1b3fee75ae19f96d5e6bcf055abbcaae3e55bcc17e6214924e4e6a9ebbe77357236b1a235e944950b851bda804",
       "prevBlockHash":
       {
              "data": "0a3d6bea020bb1a503364c37d57392342f368389bb23b05799c54d536d94749b"
       },
       "type": 1,
       "transactions": [
              Transaction1, Transaction2, &hellip;, Transaction11
       ],
       "version": 1744830465,
       "signer": "6c66ea288522990db7a0a63c9c20f532cdcb68dc3c9544fb20f7322c92ceadbb",
       "height": 39324
}
    </resp>

    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="Signature">The signature of the block. The signature was generated by the
            signer and can be used to validate that the block data was not modified by a
            node.
        </f>
        <f name="prevBlockHash">The sha3-256 hash of the last block as hex-string.</f>
        <f name="type">The block type. There are currently two block types used:
            <vals>
                -1: Only the nemesis block has this type.
                1: Regular block type.
            </vals>
        </f>
        <f name="transactions">The array of transaction structures. See
            <appa>Transaction</appa>
            for more details about this structure.
        </f>
        <f name="version">The block version. The following versions are supported.
            <li>0x68 &lt;&lt; 24 + 1 (1744830465 as 4 byte integer): the main network version</li>
            <li>0x60 &lt;&lt; 24 + 1 (1610612737 as 4 byte integer): the mijin network version</li>
            <li>0x98 &lt;&lt; 24 + 1 (-1744830463 as 4 byte integer): the test network version</li>
        </f>
        <f name="signer">The public key of the harvester of the block as hexadecimal number.</f>
        <f name="height">The height of the block. Each block has a unique height.
            Subsequent blocks differ in height by 1.
        </f>
    </fields>

    <h2>BlockChainScore</h2>

    <desc>
        <p class=NemNoSpacing>The block chain score is a measure how
            good the block chain is. The higher the score, the better the block chain is.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "score": "17a3077c927d9a7e"
}
    </resp>

    <fields>
        <f name="score">The score is an integer greater or equal to zero. It is submitted in hexadecimal format.</f>
    </fields>

    <h2>BlockHeight</h2>

    <desc>
        <p class=NemNoSpacing>The block height describes the position
            of the block within the block chain. The first block of the chain has height
            one. Each subsequent block has a height which is one higher than the previous
            block.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "height": 2649
}
    </resp>

    <fields>
        <f name="height">The height is an integer greater than zero.</f>
    </fields>

    <h2>BootNodeRequest</h2>

    <desc>
        <p class=NemNoSpacing>The BootNodeRequest JSNON object is used
            to transfer the relevant data for booting a local node to NIS. With the boot
            data NIS can create the local node object and connect to the network.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "metaData":
       {
              "application":"NIS"
       },
       "endpoint":
       {
              "protocol":"http",
              "port":7890,
              "host":"localhost"
       },
       "identity":
       {
              "private-key":"a6cbd01d04edecfaef51df9486c111abb6299c764a00206eb1d01f4587491b3f",
              "name":"Alice"
       }
}
    </resp>

    <h4>Description of the fields:</h4>

    <fields>
        <f name="metaData">Denotes the beginning of the metaData substructure.</f>
        <f name="application">The application name.</f>
        <f name="endpoint">Denotes the beginning of the endpoint substructure.</f>
        <f name="protocol">The protocol to use (only HTTP supported as for now).</f>
        <f name="port">The port to use.</f>
        <f name="host">The IP address to use.</f>
        <f name="identity">Denotes the fof the identity substructure.</f>
        <f name="private-key">The private key used for creating the identity.</f>
        <f name="name">The name of the node (can be anything).</f>
    </fields>

    <h2>CommunicationTimeStamps</h2>

    <desc>
        <p class=NemNoSpacing>Communication timestamps contain
            information about the network time of a remote NIS. NEM uses a time
            synchronization mechanism to synchronize time across the network. Each node
            maintains a network time which is the time of the computer clock plus an offset
            which compensates for the deviation from the computer clocks of other nodes.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "sendTimeStamp": 9145477789,
       "receiveTimeStamp": 9145477789
}
    </resp>

    <fields>
        <f name="sendTimeStamp">The network time at the moment the reply was sent.</f>
        <f name="receiveTimeStamp">The network time at the moment the request was received.</f>
    </fields>

    <h2>ExplorerBlockViewModel</h2>

    <desc>
        <p class=NemNoSpacing>The following structure is used by the
            NEM block chain explorer for convenience reason. The data is similar but not
            identical to that of a <a href="#block">Block</a>.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
        "data":[
            {
                "txes":[
                    &lt;ExplorerTransferViewModel&gt;,
                    &vellip;
                    &lt;ExplorerTransferViewModel&gt;
                ],
                "block": &lt;Block&gt; ,
                "hash":"a6f62c62eedf4fafe6991e5cf31eae440963577c919f4eae86b4db8f8e572dce",
                "difficulty": 23456345897
            },
            &hellip;
        ]
}
    </resp>

    <fields>
        <f name="txes">Array containing the transactions of the block.</f>
        <f name="&lt;ExplorerTransferViewModel&gt;">The ExplorerBlockViewModel object as described in <a href="#explorerTransferViewModel">ExplorerTransferViewModel</a>
        </f>
        <f name="block">Entry containing a JSON block object.</f>
        <f name="&lt;Block&gt;">The Block object as described in
            <appa>Block</appa>
        </f>
        <f name="hash">The hash of the block as hexadecimal string.</f>
        <f name="difficulty">The block difficulty.</f>
    </fields>

    <h2>ExplorerTransferViewModel</h2>

    <desc>
        <p class=NemNoSpacing>The following structure is used by the
            NEM block chain explorer for convenience reason. The data is similar but not
            identical to that of a <a href="#transaction">Transaction</a> structure.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
       "tx": &lt;Transaction&gt;,
       "hash": "5cba4614e52af19417fb53c4bdf442a57b9f558aee17ece530a5220da55cf47d",
       "innerHash": "ae3b107f1216e1ccf12b6f3c3c555bc1d95311747338ce66f539ea2c18c0aa57"
}
    </resp>

    <fields>
        <f name="tx">Entry containing the JSON Transaction object.</f>
        <f name="&lt;Transaction&gt;">The Transaction object. Depending on the type of the transaction the structure will look different. See
            <appa>Transaction objects</appa>
            for the different transaction types.
        </f>
        <f name="hash">The hash of the transaction.</f>
        <f name="innerHash">The hash of the inner transaction. This entry is only available for multisig transactions</f>
    </fields>

    <h2>ExtendedNodeExperiencePair</h2>

    <desc>
        <p class=NemNoSpacing>When exchanging data with other nodes
            the result of the communication is divided into three different outcomes:
            success, neutral and failure. In the cases of success and failure the result is
            saved to be able to judge the quality of a node. This has influence on the
            probability that a certain node is selected as partner.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{ 
       "node": 
       { 
              &lt;Node&gt; 
       }, 
       "syncs": 822, 
       "experience": 
       { 
              "s": 357, 
              "f": 0 
       } 
} 
    </resp>

    <fields>
        <f name="node">Denotes the beginning of the of the Node substructure.</f>
        <f name="&lt;Node&gt;">The remote Node object as described in <a href="#node">Node</a>.</f>
        <f name="syncs">The number of synchronization attempts the node had with the remote node.</f>
        <f name="experience">Denotes the beginning of the of the NodeExperience substructure.</f>
        <f name="s">The number of successful communications with the remote node.</f>
        <f name="f">The number of failed communications with the remote node.</f>
    </fields>

    <h2>HarvestInfo</h2>

    <desc>
        <p class=NemNoSpacing>A HarvestInfo object contains
            information about a block that an account harvested.</p>
    </desc>

    <h4>JSON structure by example:</h4>
    <resp>
{ 
       "timeStamp": 8963798, 
       "id": 254378,
       "difficulty": 46534789865332,
       "totalFee": 2041299054, 
       "height": 38453 
} 
    </resp>

    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="id">The database id for the harvested block.</f>
        <f name="difficulty">The block difficulty. The initial difficulty was set to 100000000000000. The block difficulty is always between one tenth and ten
            times the initial difficulty.
        </f>
        <f name="totalFee">The total fee collected by harvesting the block.</f>
        <f name="height">The height of the harvested block.</f>
    </fields>

    <h2>KeyPairViewModel</h2>

    <desc>
        <p class=NemNoSpacing>A KeyPairViewModel object contains
            information about a new account. Information includes the private key,
            the public key and the address</p>
    </desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
    "privateKey": "0962c6505d02123c40e858ff8ef21e2b7b5466be12c4770e3bf557aae828390f",
    "publicKey": "c2e19751291d01140e62ece9ee3923120766c6302e1099b04014fe1009bc89d3",
    "address": "NCKMNCU3STBWBR7E3XD2LR7WSIXF5IVJIDBHBZQT"
}
    </resp>

    <fields>
        <f name="privateKey">The private key of the account as hexadeciaml string.</f>
        <f name="publicKey">The public key of the account as hexadeciaml string.</f>
        <f name="address">The address of the account.</f>
    </fields>

    <h2>Transaction objects</h2>

    <h3>ImportanceTransferTransaction</h3>
    <desc>
        <p class=NemNoSpacing>NIS has the ability to transfer the importance of one
            account to another account for harvesting. The account receiving the
            importance is called the remote account. Importance transfer transactions
            are part of the secure harvesting feature of NEM. Once an importance
            transaction has been included in a block it needs 6 hours to become active.</p>
    </desc>

    <h4>JSON structure by example (main network):</h4>
    <resp>
{
    "timeStamp": 9111526,
    "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
    "fee": 3000000,
    "mode": 1,
    "remoteAccount": "cc6c9485d15b992501e57fe3799487e99de272f79c5442de94eeb998b45e0144",
    "type": 2049,
    "deadline": 9154726,
    "version": 1744830465,
    "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
}
    </resp>

    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of
            the nemesis block.
        </f>
        <f name="signature">The transaction signature (missing if part of a multisig
            transaction).
        </f>
        <f name="fee">The fee for the transaction. The higher the fee, the higher the
            priority of the transaction. Transactions with high priority get included in
            a block before transactions with lower priority.
        </f>
        <f name="mode">
            The mode. Possible values are:
            <vals>
                1: Activate remote harvesting.
                2: Deactivate remote harvesting.
            </vals>
        </f>
        <f name="remoteAccount">The public key of the receiving account as
            hexadecimal string.
        </f>
        <f name="type">The transaction type.</f>
        <f name="deadline">The deadline of the transaction. The deadline is given as
            the number of seconds elapsed since the creation of the nemesis block.
            If a transaction does not get included in a block before the deadline is
            reached, it is deleted.
        </f>
        <f name="version">The version of the structure.</f>
        <f name="signer">The public key of the account that created the transaction.</f>
    </fields>

    <h3>MosaicDefinitionCreationTransaction</h3>
    <desc>
        <p class=NemNoSpacing>Before a mosaic can be created or transferred, a corresponding definition of the mosaic
            has to be created and published to the network. This is done via a mosaic definition creation transaction.</p>
    </desc>

    <h4>JSON structure by example (test network):</h4>
    <resp>
{
        "timeStamp": 9111526,
        "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
        "fee": 108000000,
        "type": 16385,
        "deadline": 9154726,
        "version": -1744830463,
        "signer": "cbda3edb771d42801a5c6ce0725f9374efade19a8933d6ac22ccfa50c777d0f9",
        "creationFee": 50000000000,
        "creationFeeSink": "53e140b5947f104cabc2d6fe8baedbc30ef9a0609c717d9613de593ec2a266d3",
        "mosaicDefinition": {
            "creator": "cbda3edb771d42801a5c6ce0725f9374efade19a8933d6ac22ccfa50c777d0f9",
            "description": "precious vouchers",
            "id": {
                "namespaceId": "alice.vouchers",
                "name": "Alice's gift vouchers"
            },
            "properties": [{
                    "name": "divisibility",
                    "value": "3"
                },{
                    "name": "initialSupply",
                    "value": "1000"
                },{
                    "name": "supplyMutable",
                    "value": "false"
                },{
                    "name": "transferable",
                    "value": "true"
                }
            ],
            "levy": {
                "type": 1,
                "recipient": "TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
                "mosaicId": {
                    "namespaceId": "nem",
                    "name": "xem"
                },
                "fee": 1000
            }
        }
}
    </resp>

    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="signature">The transaction signature (missing if part of a multisig transaction).</f>
        <f name="fee">The fee for the transaction. The higher the fee, the higher the
            priority of the transaction. Transactions with high priority get included in
            a block before transactions with lower priority.
        </f>
        <f name="type">The transaction type.</f>
        <f name="deadline">The deadline of the transaction. The deadline is given as
            the number of seconds elapsed since the creation of the nemesis block.
            If a transaction does not get included in a block before the deadline is
            reached, it is deleted.
        </f>
        <f name="version">The version of the structure.</f>
        <f name="signer">The public key of the account that created the transaction.</f>
        <f name="creationFee">The fee for the creation of the mosaic.</f>
        <f name="creationFeeSink">The public key of the account to which the creation fee is tranferred.</f>
        <f name="mosaicDefinition">The actual mosaic definition. See <a href="#mosaicDefinition">MosaicDefinition</a> for details.</f>
    </fields>

    <h3>MosaicSupplyChangeTransaction</h3>
    <desc>
        <p class=NemNoSpacing>In case a mosaic definition has the property 'supplyMutable' set to true, the creator of the mosaic definition
            can change the supply, i.e. increase or decrease the supply.</p>
    </desc>

    <h4>JSON structure by example (test network):</h4>
    <resp>
{
        "timeStamp": 9111526,
        "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
        "fee": 108000000,
        "type": 16386,
        "deadline": 9154726,
        "version": -1744830463,
        "signer": "d99e88c90da71a4b0d848454e59e296c9ef7a8f018f3eaa3a198dc460b6621a4",
        "supplyType": 1,
        "delta": 123,
        "mosaicId": {
            "namespaceId": "alice.vouchers",
            "name": "gift vouchers"
        }
}
    </resp>

    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="signature">The transaction signature (missing if part of a multisig transaction).</f>
        <f name="fee">The fee for the transaction. The higher the fee, the higher the
            priority of the transaction. Transactions with high priority get included in
            a block before transactions with lower priority.
        </f>
        <f name="type">The transaction type.</f>
        <f name="deadline">The deadline of the transaction. The deadline is given as
            the number of seconds elapsed since the creation of the nemesis block.
            If a transaction does not get included in a block before the deadline is
            reached, it is deleted.
        </f>
        <f name="version">The version of the structure.</f>
        <f name="signer">The public key of the account that created the transaction.</f>
        <f name="supplyType">The supply type. Supported supply types are:
            <li>1: Increase in supply.</li>
            <li>2: Decrease in supply.</li>
        </f>
        <f name="delta">The supply change in units for the mosaic.</f>
        <f name="mosaicId">The mosaic id. See <a href="#mosaicId">MosaicId</a> for details.</f>
    </fields>

    <h3>MultisigAggregateModificationTransaction</h3>
    <desc>
        <p>Multisig aggregate modification transactions are part of the NEM's multisig
            account system. A multisig aggregate modification transaction holds an array
            of multisig cosignatory modifications and a single multisig minimum cosignatories
            modification inside the transaction. A multisig aggregate
            modification transaction can be wrapped by a multisig transaction.
            Aggregate modification transactions that use the minCosignatories field need to have
            version 0x68000002 (decimal 1744830466) for mainnet, 0x98000002 (decimal -1744830462)
            for testnet and 0x60000002 (decimal 1610612738) for mijin network.
        </p>
    </desc>

    <h4>JSON structure by example (main network):</h4>
    <resp>
{
    "timeStamp": 9111526,
    "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
    "fee": 3000000,
    "type": 257,
    "deadline": 9154726,
    "version": 1744830466,
    "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a",
    "modifications": [
        &lt;MultisigCosignatoryModification&gt;,
        &lt;MultisigCosignatoryModification&gt;
    ],
    "minCosignatories" : {
        "relativeChange" : 2
    }
}
    </resp>
    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="signature">The transaction signature (missing if part of a multisig transaction).</f>
        <f name="fee">The fee for the transaction. The higher the fee, the higher the priority of the transaction. Transactions with high priority get included
            in a block before transactions with lower priority.
        </f>
        <f name="type">The transaction type.</f>
        <f name="deadline">The deadline of the transaction. The deadline is given as the number of seconds elapsed since the creation of the nemesis block. If a
            transaction does not get included in a block before the deadline is reached, it is deleted.
        </f>
        <f name="version">The version of the structure.</f>
        <f name="signer">The public key of the account that created the transaction.</f>
        <f name="modifications">The JSON array of multisig modifications.</f>
        <f name="minCosignatories">JSON object that holds the minimum cosignatories modification.</f>
        <f name="relativeChange">Value indicating the relative change of the minimum cosignatories.</f>
    </fields>

    <h3>MultisigCosignatoryModification</h3>
    <desc><p>Multisig cosignatory modifications are part of the NEM's multisig account system.
        With a multisig cosignatory modification a cosignatory is added to or deleted from a multisig
        account. Multisig cosignatory modifications are part of a multisig aggregate modification
        transactions, see details there.</p></desc>
    <h4>JSON structure by example:</h4>
    <resp>
{
    "modificationType": 1,
    "cosignatoryAccount": "213150649f51d6e9113316cbec5bf752ef7968c1e823a28f19821e91daf848be"
}
    </resp>
    <fields>
        <f name="modificationType">The type of modification. Possible values are:
            <vals>
                1: Add a new cosignatory.
                2: Delete an existing cosignatory.
            </vals>
        </f>
        <f name="cosignatoryAccount">The public key of the cosignatory account as hexadecimal string</f>
    </fields>

    <h3>MultisigSignatureTransaction</h3>
    <desc><p>Multisig signature transactions are part of the NEM's multisig account
        system. Multisig signature transactions are included in the corresponding
        multisig transaction and are the way a cosignatory of a multisig account can
        sign a multisig transaction for that account.</p></desc>

    <h4>JSON structure by example (test network):</h4>
    <resp>
{
    "timeStamp": 9111526,
    "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
    "fee": 3000000,
    "type": 257,
    "deadline": 9154726,
    "version": -1744830463,
    "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a",
    "otherHash": {
        "data": "44e4968e5aa35fe182d4def5958e23cf941c4bf809364afb4431ebbf6a18c039"
    },
    "otherAccount": "TDGIMREMR5NSRFUOMPI5OOHLDATCABNPC5ID2SVA"
}
    </resp>
    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="signature">The transaction signature.</f>
        <f name="fee">The fee for the transaction.</f>
        <f name="type">The transaction type.</f>
        <f name="deadline">The deadline of the transaction. The deadline is given as the number of seconds elapsed since the creation of the nemesis block. If a
            transaction does not get included in a block before the deadline is reached, it is deleted.
        </f>
        <f name="version">The version of the structure.</f>
        <f name="signer">The public key of the account that created the transaction.</f>
        <f name="otherHash">The hash of the inner transaction of the corresponding multisig transaction.</f>
        <f name="otherAccount">The address of the corresponding multisig account.</f>
    </fields>

    <h3>MultisigTransaction</h3>
    <desc><p>Multisig transaction are the only way to make transaction from
        a multisig account to another account. A multisig transaction carries another
        transaction inside (often referred to as "inner" transaction). The inner
        transaction can be a transfer, an importance transfer or an aggregate
        modification transaction. A multisig transaction also has multisig signature
        transactions from the cosignatories of the multisig account inside.</p></desc>

    <h4>JSON structure by example (test network):</h4>
    <resp>
{
    "timeStamp": 9111526,
    "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
    "fee": 3000000,
    "type": 257,
    "deadline": 9154726,
    "version": -1744830463,
    "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a",
    "otherTrans": &lt;inner transaction&gt;,
    "signatures":[
        &lt;MultisigSignatureTransaction&gt;,
        &lt;MultisigSignatureTransaction&gt;
    ]
}
    </resp>
    <fields>
        <f name="timeStamp"> The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="signature"> The transaction signature.</f>
        <f name="fee"> The fee for the transaction.</f>
        <f name="type"> The transaction type.</f>
        <f name="deadline"> The deadline of the transaction. The deadline is given as the number of seconds elapsed since the creation of the nemesis block. If
            a transaction does not get included in a block before the deadline is reached, it is deleted.
        </f>
        <f name="version"> The version of the structure.</f>
        <f name="signer"> The public key of the account that created the transaction.</f>
        <f name="otherTrans"> The inner transaction. The inner transaction can be a transfer transaction, an importance transfer transaction or a multisig
            aggregate modification transaction. The inner transaction does not have a valid signature.
        </f>
        <f name="signatures"> The JSON array of MulsigSignatureTransaction objects.</f>
    </fields>

    <h3>ProvisionNamespaceTransaction</h3>
    <desc>
        <p class=NemNoSpacing>Accounts can rent a namespace for one year and after a year renew the contract.
            This is done via a ProvisionNamespaceTransaction.</p>
    </desc>

    <h4>JSON structure by example (test network):</h4>
    <resp>
{
        "timeStamp": 9111526,
        "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
        "fee": 108000000,
        "type": 8193,
        "deadline": 9154726,
        "version": -1744830463,
        "signer": "d99e88c90da71a4b0d848454e59e296c9ef7a8f018f3eaa3a198dc460b6621a4",
        "rentalFeeSink": "3e82e1c1e4a75adaa3cba8c101c3cd31d9817a2eb966eb3b511fb2ed45b8e262",
        "rentalFee": 5000000000,
        "newPart": "voucher",
        "parent": "alice"
}
    </resp>

    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="signature">The transaction signature (missing if part of a multisig transaction).</f>
        <f name="fee">The fee for the transaction. The higher the fee, the higher the
            priority of the transaction. Transactions with high priority get included in
            a block before transactions with lower priority.
        </f>
        <f name="type">The transaction type.</f>
        <f name="deadline">The deadline of the transaction. The deadline is given as
            the number of seconds elapsed since the creation of the nemesis block.
            If a transaction does not get included in a block before the deadline is
            reached, it is deleted.
        </f>
        <f name="version">The version of the structure.</f>
        <f name="signer">The public key of the account that created the transaction.</f>
        <f name="rentalFeeSink">The public key of the account to which the rental fee is transferred.</f>
        <f name="rentalFee">The fee for renting the namespace.</f>
        <f name="newPart">The new part which is concatenated to the parent with a '.' as separator.</f>
        <f name="parent">The parent namespace. This can be null if the transaction rents a root namespace.</f>
    </fields>

    <h3>TransferTransaction</h3>

    <desc><p class=NemNoSpacing>Transfer transactions contain data about transfers of XEM or mosaics to another account.
        There are two version of transfer transactions, version 1 and version 2. Version 1 transfer transaction are only capable of transferring XEM and
        a message while version 2 transfer transactions additionally can transfer a set of mosaics.
    </p></desc>

    <h4>JSON structure by example (v1 transfer transaction, test network):</h4>
    <resp>
{
        "timeStamp": 9111526,
        "amount": 1000000000,
        "signature": "651a19ccd09c1e0f8b25f6a0aac5825b0a20f158ca4e0d78f2abd904a3966b6e3599a47b9ff199a3a6e1152231116fa4639fec684a56909c22cbf6db66613901",
        "fee": 3000000,
        "recipient": "TDGIMREMR5NSRFUOMPI5OOHLDATCABNPC5ID2SVA",
        "type": 257,
        "deadline": 9154726,
        "message":
        {
        "payload": "74657374207472616e73616374696f6e",
        "type": 1
        },
        "version": -1744830463,
        "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a"
}
    </resp>

    <h4>JSON structure by example (v2 transfer transaction, test network):</h4>
    <resp>
{
        "timeStamp": 9111526,
        "amount": 123000000,
        "signature": "fad7ea2b5df5f7846f45fd9983a75ad8d333af3660f4f0d355864420f4482605d675e89d97177385338b226097342b4222add52c5397423f9eaf6b01fe3ef70c",
        "fee": 3000000,
        "recipient": "TBEH27FNRS43FNH3PXE4XN3H7HXA37H77APSZW46",
        "type": 257,
        "deadline": 9154726,
        "message":
        {
            "payload": "74657374207472616e73616374696f6e",
            "type": 1
        },
        "version": -1744830462,
        "signer": "cb4ef3709d25ccd0c022b2d53e4ce31478ebc4bf177b1b54482afb8e55692521",
        "mosaics":[{
            "mosaicId":{
                "namespaceId": "id0",
                "name": "name0"
            },
            "quantity": 10
        },{
            "mosaicId":{
                "namespaceId": "id1",
                "name": "name1"
            },
            "quantity": 11
        }]
}
    </resp>

    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="amount">The amount of micro NEM that is transferred from sender to recipient.</f>
        <f name="signature">The transaction signature.</f>
        <f name="fee">The fee for the transaction. The higher the fee, the higher the
            priority of the transaction. Transactions with high priority get included in
            a block before transactions with lower priority.
        </f>
        <f name="recipient">The address of the recipient.</f>
        <f name="type">The transaction type.</f>
        <f name="deadline">The deadline of the transaction. The deadline is given as the
            number of seconds elapsed since the creation of the nemesis block. If a
            transaction does not get included in a block before the deadline is reached, it
            is deleted.
        </f>
        <f name="message">Optionally a transaction can contain a message. In this case the
            transaction contains a message substructure. If not the field is null.
        </f>
        <f name="payload">
            Optional field in case the transaction contains a message. The
            payload is the actual (possibly encrypted) message data.
        </f>
        <f name="type">
            Optional field in case the transaction contains a message. The
            field holds the message type information. Possible message types are:
            <vals>
                1: The message is not encrypted.
                2: The message is encrypted.
            </vals>
        </f>
        <f name="version">The version of the structure.</f>
        <f name="signer">The public key of the account that created the transaction.</f>
        <f name="mosaics">The array of <a href="#mosaic">Mosaic</a> objects.</f>
    </fields>

    <h2>Mosaic</h2>
    <desc><p>A mosaic describes an instance of a mosaic definition.
        Mosaics can be transferred by means of a transfer transaction.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
        "mosaicId": {
            "namespaceId": "alice.drinks",
            "name": "orange juice"
        },
        "quantity": 123000
}
    </resp>

    <fields>
        <f name="mosaicId">The mosaic id. See <a href="#mosaicId">MosaicId</a></f>
        <f name="quantity">The mosaic quantity. The quantity is always given in smallest units for the mosaic,
            i.e. if it has a divisibility of 3 the quantity is given in millis.
        </f>
    </fields>

    <h2>MosaicDefinition</h2>
    <desc><p>A mosaic definition describes an asset class.
        Some fields are mandatory while others are optional.
        The properties of a mosaic definition always have a default value and only need to be supplied if they differ from the default value.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
        "creator": "10cfe522fe23c015b8ab24ef6a0c32c5de78eb55b2152ed07b6a092121187100",
        "id": {
            "namespaceId": "alice.drinks",
            "name": "orange juice"
        },
        "description": "A healthy drink with lots of vitamins",
        "properties": [{
            "name": "divisibility",
            "value": "3"
        },{
            "name": "initialSupply",
            "value": "1000"
        },{
            "name": "supplyMutable",
            "value": "false"
        },{
            "name": "transferable",
            "value": "true"
        }],
        "levy": {
            "type": 1,
            "recipient": "TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
            "mosaicId": {
                "namespaceId": "alice.drinks",
                "name": "orange juice"
            },
            "fee": 1000
        }
}
    </resp>

    <fields>
        <f name="creator">The public key of the mosaic definition creator.</f>
        <f name="id">The mosaic id. See <a href="#mosaicId">MosaicId</a>.</f>
        <f name="description">The mosaic description. The description may have a length of up to 512 characters and cannot be empty.</f>
        <f name="properties">The mosaic properties.
            The properties may be an empty array in which case default values for all properties are applied.
            See <a href="#mosaicProperties">MosaicProperties</a> for further details.
        </f>
        <f name="levy">The optional levy for the mosaic. A creator can demand that each mosaic transfer induces an additional fee.
            See <a href="#mosaicLevy">MosaicLevy</a> for further details.
        </f>
    </fields>

    <h2>MosaicDefinitionMetaDataPair</h2>
    <desc><p>A mosaic definition consists of a database id and a mosaic definition object. The id is needed for requests that support paging.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
        "meta" {
            "id": 3541
        }
        "mosaic": {
            "creator": "10cfe522fe23c015b8ab24ef6a0c32c5de78eb55b2152ed07b6a092121187100",
            "id": {
                "namespaceId": "alice.drinks",
                "name": "orange juice"
            },
            "description": "A healthy drink with lots of vitamins",
            "properties": [
            ]
        }
}
    </resp>

    <fields>
        <f name="meta">The label for the meta data object.</f>
        <f name="id">The id for the mosaic definition object.</f>
        <f name="mosaic">The label for the mosaic definition object. See <a href="#mosaicDefinition">MosaicDefinition</a> for a detailed
            description of the object.
        </f>
        <f name="creator">The public key of the mosaic definition creator.</f>
        <f name="id">The mosaic id. See <a href="#mosaicId">MosaicId.</a></f>
        <f name="description">The mosaic description. The description may have a length of up to 512 characters and cannot be empty.</f>
        <f name="properties">The mosaic properties.</f>
    </fields>

    <h2>MosaicProperties</h2>
    <desc><p>Each mosaic definition comes with a set of properties.
        Each property has a default value which will be applied in case it was not specified.
        Future release may add additional properties to the set of available properties.
        The available properties and their default values are:
        <li>
            <b>divisibility:</b> defines the smallest sub-unit that a mosaic can be divided into.
            A divisibility of 0 means that only entire units can be transferred while a divisibility of 3 means the mosaic can be transferred in milli-units.
        </li>
        <li>
            <b>initialSupply:</b> defines how many units of the mosaic are initially created. These mosaics are credited to the creator of the mosaic.
            The initial supply has an upper limit of 9,000,000,000 units.
        </li>
        <li>
            <b>supplyMutable:</b> determines whether or not the supply can be changed by the creator at a later point using a
            <a href="#mosaicSupplyChangeTransaction">MosaicSupplyChangeTransaction</a>. Possible values are "true" and "false",
            the former meaning the supply can be changed and the latter that the supply is fixed for all times.
        </li>
        <li>
            <b>transferable:</b> determines whether or not the a mosaic can be transferred to a user other than the creator.
            In certain scenarios it is not wanted that user are able to trade the mosaic (for example when the mosaic represents bonus points which
            the company does not want to be tranferable to other users).
            Possible values are "true" and "false", the former meaning the mosaic can be arbitrarily transferred among users
            and the latter meaning the mosaic can only be transferred to and from the creator.
        </li>

    </p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
[{
        "name": "divisibility",
        "value": "3"
        },{
        "name": "initialSupply",
        "value": "1000"
        },{
        "name": "supplyMutable",
        "value": "false"
        },{
        "name": "transferable",
        "value": "true"
}]
    </resp>

    <fields>
        <f name="name">The name of the mosaic property.</f>
        <f name="value">The name of the mosaic property.</f>
    </fields>

    <h2>MosaicLevy</h2>
    <desc><p>A mosaic definition can optionally specify a levy for transferring those mosaics.
        This might be needed by legal entities needing to collect some taxes for transfers.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
        "type": 1,
        "recipient": "TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
        "mosaicId":  {
            "namespaceId": "nem",
            "name": "xem"
        },
        "fee": 1000
}
    </resp>

    <fields>
        <f name="type">The levy type. The following types are supported:
            <li>1: The levy is an absolute fee. The field 'fee' states how many sub-units of the specified mosaic will be transferred to the recipient.</li>
            <li>2: The levy is calculated from the transferred amount.
                The field 'fee' states how many percentiles of the transferred quantity will transferred to the recipient.
            </li>
        </f>
        <f name="recipient">The recipient of the levy.</f>
        <f name="mosaicId">The mosaic in which the levy is paid.</f>
        <f name="recipient">The fee. The interpretation is dependent on the type of the levy</f>
    </fields>

    <h2>MosaicId</h2>
    <desc><p>A mosaic id uniquely identifies an underlying mosaic definition.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
        "namespaceId": "alice.drinks",
        "name": "orange juice"
}
    </resp>

    <fields>
        <f name="namespaceId">The corresponding namespace id. See the description of the structure <a href="#namespace">Namespace.</a> for details.</f>
        <f name="name">The name of the mosaic definition.</f>
    </fields>

    <h2>Namespace</h2>
    <desc><p>A namespace is the NEM version of a domain. You can rent a namespace for the duration of a year by paying a fee.
        The naming of the parts of a namespace has certain restrictions, see the corresponding chapter on namespaces.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
        "fqn": "makoto.metal.coins",
        "owner": TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
        "height": 13465
}
    </resp>

    <fields>
        <f name="fqn">The fully qualified name of the namespace, also named namespace id.</f>
        <f name="owner">The owner of the namespace.</f>
        <f name="height">The height at which the ownership begins.</f>
    </fields>

    <h2>NamespaceMetaDataPair</h2>
    <desc><p>A namespace consists of a namespace object and a database id. the id is needed for requests that support paging.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
        "meta":{
            "id":26264,
        },
        "namespace":{
            "fqn": "makoto.metal.coins",
            "owner": TD3RXTHBLK6J3UD2BH2PXSOFLPWZOTR34WCG4HXH",
            "height": 13465
        }
}
    </resp>

    <fields>
        <f name="meta">The label for the meta data object.</f>
        <f name="id">The database id for the namespace object.</f>
        <f name="namespace">The label for the namespace object.</f>
        <f name="fqn">The fully qualified name of the namespace, also named namespace id.</f>
        <f name="owner">The owner of the namespace.</f>
        <f name="height">The height at which the ownership begins.</f>
    </fields>

    <h2>NemAnnounceResult</h2>
    <desc><p>The NemAnnounceResult extends the <a href="#nemRequestResult">NemRequestResult</a>
        by supplying the additional fields 'transactionHash' and in case of a multisig transaction 'innerTransactionHash'.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{
        "type": 4,
        "code": 6,
        "message": "status",
        "transactionHash": {
        "data":"c1786437336da077cd572a27710c40c378610e8d33880bcb7bdb0a42e3d35586"
        },
        "innerTransactionHash": {
        "data": "44e4968e5aa35fe182d4def5958e23cf941c4bf809364afb4431ebbf6a18c039"
        }
}
    </resp>
    <fields>
        <f name="type"> See description of <a href="#nemRequestResult">NemRequestResult</a>.</f>
        <f name="code"> See description of <a href="#nemRequestResult">NemRequestResult</a>.</f>
        <f name="message"> See description of <a href="#nemRequestResult">NemRequestResult</a>.</f>
        <f name="transactionHash"> The JSON hash object of the transaction.</f>
        <f name="innerTransactionHash"> The JSON hash object of the inner transaction or null if the transaction is not a multisig transaction.</f>
    </fields>

    <h2>NemAsyncTimerVisitor</h2>
    <desc><p>NIS uses timers to schedule periodic
        tasks. Those tasks are monitored and their result is memorized. The
        NemAsyncTimeVisitor structure holds the information.</p></desc>

    <h4>JSON structure by example:</h4>
    <resp>
{ 
       "last-delay-time": 3000, 
       "executions": 1024, 
       "failures": 0, 
       "successes": 1024, 
       "last-operation-start-time": 9317695, 
       "is-executing": 0, 
       "name": "FORAGING", 
       "average-operation-time": 0, 
       "last-operation-time": 0 
} 
    </resp>

    <fields>
        <f name="last-delay-time">The number of milliseconds since the last execution of the timer.</f>
        <f name="executions">The number of times the task was executed.</f>
        <f name="failures">The number times the task failed.</f>
        <f name="successes">The number times the task was successful.</f>
        <f name="last-operation-start-time">The time at which the task started last time.</f>
        <f name="is-executing">True if the task is executing, false otherwise.</f>
        <f name="name">The name of the task.</f>
        <f name="average-operation-time">The number of seconds the task needed on average.</f>
        <f name="last-operation-time">The number of seconds the task needed the last time.</f>
    </fields>

    <h2>NemRequestResult</h2>

    <p>Some requests such as announcing a new
        transaction return detailed information about the outcome of the request. In
        those cases the result of the request is returned in a special JSON object
        called NemRequestResult. The structure is typically used for requests that
        perform validation or return a status.</p>

    <h4>JSON structure by example:</h4>

    <resp>
{ 
       "type": 4, 
       "code": 6, 
       "message": "status" 
}  
    </resp>

    <fields>
        <f name="type"><p>The type is dependent on the request which was answered.</p>

            <p>The interpretation of the code field depends on the type. Currently the following
                types are supported:</p>

            <p></p>
            <vals>
                1: The result is a validation result.
                2: The result is a heart beat result.
                4: The result indicates a status.
            </vals>
        </f>
        <f name="code">The meaning of the code is dependent on the type.
            For type 1 (validation result) only 0 and 1 mean there was no
            failure. For a complete list of validation results see
            <alnk>Appendix B: NIS Errors</alnk>
            The following codes are the most frequent ones occurring:
            <vals>
                0:Neutral result. A typical example would be that a node validates an incoming transaction and realizes that it already knows about the transaction. In this case it is neither a success (meaning the node has a new transaction) nor a failure (because the transaction itself is valid).
                1:Success result. A typical example would be that a node validates a new valid transaction.
                2:Unknown failure. The validation failed for unknown reasons.
                3:The entity that was validated has already past its deadline.
                4:The entity used a deadline which lies too far in the future.
                5:There was an account involved which had an insufficient balance to perform the operation.
                6:The message supplied with the transaction is too large.
                7:The hash of the entity which got validated is already in the database.
                8:The signature of the entity could not be validated.
                9:The entity used a timestamp that lies too far in the past.
                10:The entity used a timestamp that lies in the future which is not acceptable.
                11:The entity is unusable.
                12:The score of the remote block chain is inferior (although a superior score was promised).
                13:The remote block chain failed validation.
                14:There was a conflicting importance transfer detected.
                15:There were too many transaction in the supplied block.
                16:The block contains a transaction that was signed by the harvester.
                17:A previous importance transaction conflicts with a new transaction.
                18:An importance transfer activation was attempted while previous one is active.
                19:An importance transfer deactivation was attempted but is not active.
            </vals>
            <p></p>

            <p>For type 2 the following codes are supported:</p>
            <vals>
                1:Successful heart beat detected.
            </vals>
            <p></p>

            <p>For type 3 the following codes are supported:</p>
            <vals>
                0:Unknown status.
                1:NIS is stopped.
                2:NIS is starting.
                3:NIS is running.
                4:NIS is booting the local node (implies NIS is running).
                5:The local node is booted (implies NIS is running).
                6:The local node is synchronized (implies NIS is running and the local node is booted).
                7:There is no remote node available (implies NIS is running and the local node is booted).
                8:NIS is currently loading the block chain.
            </vals>
        </f>
    </fields>

    <h2>NisNodeInfo</h2>

    <desc>
        <p class=NemNoSpacing>The NisNodeInfo object provides detailed information about a node.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{ 
       "node": { 
              &lt;Node&gt; 
       }, 
       "nisInfo": { 
              &lt;ApplicationMetaData&gt; 
       } 
} 
    </resp>

    <fields>
        <f name="node">Denotes the beginning of the node substructure.</f>
        <f name="&lt;Node&gt;">The Node object as described in <a href="#node">Node</a>.</f>
        <f name="nisInfo">Denotes the beginning of the application meta data substructure.</f>
        <f name="&lt;ApplicationMetaData&gt;">The ApplicationMetaData object as described in <a href="#applicationMetaData">ApplicationMetaData</a>.</f>
    </fields>

    <h2>Node</h2>

    <desc>
        <p class=NemNoSpacing>Nodes are the entities that perform
            communication in the network like sending and receiving data. A node has an
            identity which is tied to an account through which the node can identify itself
            to the network. The communication is done through the endpoint of the node.
            Additionally a node provides meta data information.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{ 
       "metaData": 
       {
              "features": 1,
              "networkId": 104,
              "application": "NIS", 
              "version": "0.4.30-BETA", 
              "platform": "Oracle Corporation (1.8.0_05) on Windows 8.1" 
       }, 
       "endpoint": 
       { 
              "protocol": "http", 
              "port": 7890, 
              "host": "85.25.36.97" 
       }, 
       "identity": 
       { 
              "name": "Hi, I am Alice2", 
              "public-key": "3302e7703ee9f364c25bbfebb9c12ac91fa9dcd69e09a5d4f3830d71505a2350" 
       } 
} 
    </resp>

    <fields>
        <f name="metaData">Denotes the beginning of the meta data substructure.</f>
        <f name="features">The number of features the nodes has.</f>
        <f name="networkId"><p>The network id. The following network ids are supported:</p>
            <li>104 (hex 0x68): The main network id.</li>
            <li>96 (hex 0x60): The mijin network id.</li>
            <li>152 (hex 0x98): The test network id.</li>
        </f>
        <f name="application">The name of the application that is running the node.</f>
        <f name="version">The version of the application.</f>
        <f name="platform">The underlying platform (OS, java version).</f>
        <f name="endpoint">Denotes the beginning of the endpoint substructure.</f>
        <f name="protocol">The protocol used for the communication (HTTP or HTTPS).</f>
        <f name="port">The port used for the communication.</f>
        <f name="host">The IP address of the endpoint.</f>
        <f name="identity">Denotes the beginning of the identity substructure.</f>
        <f name="name">The name of the node.</f>
        <f name="public-key">The public key used to identify the node.</f>
    </fields>

    <h2>NodeCollection</h2>

    <desc>
        <p class=NemNoSpacing>A NodeCollection object holds arrays of nodes
            with different statuses. The following statuses are supported:</p>
    </desc>

    <fields>
        <f name="inactive">A connection to the node cannot be established.</f>
        <f name="active">A connection can be established and the remote node responds in a timely manner.</f>
        <f name="busy">A connection can be established but the node cannot provide
            information within the timeout limits.
        </f>
        <f name="failure">A fatal error occurs when trying to establish a connection or the
            node couldn't authenticate itself correctly.
        </f>
        <f name="data">Generic status indicating the node collection just lists nodes without
            saying anything about the status of the node.
        </f>
    </fields>

    <h4>JSON structure by example:</h4>

    <resp>
{ 
       "inactive": [ 
              &lt;Node&gt;, 
              &lt;Node&gt; 
       ], 
       "active": [ 
              &lt;Node&gt;, 
              &lt;Node&gt; 
       ], 
       "busy": [ 
              &lt;Node&gt;, 
              &lt;Node&gt; 
       ], 
       "failure": [ 
              &lt;Node&gt;, 
              &lt;Node&gt; 
       ], 
} 
    </resp>

    <fields>
        <f name="inactive">Denotes the beginning of the array of inactive nodes.</f>
        <f name="active">Denotes the beginning of the array of active nodes.</f>
        <f name="busy">Denotes the beginning of the array of busy nodes.</f>
        <f name="failure">Denotes the beginning of the array of failing nodes.</f>
        <f name="&lt;Node&gt;">The Node object as described in <a href="#node">Node</a>.</f>
    </fields>

    <h2>PrivateKey</h2>

    <desc>
        <p class=NemNoSpacing>A private key is a key to an account.
            Anyone having the private key to an account can initiate any account related
            action. <strong>Therefore a private key must be kept secret at all costs.</strong></p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
    "value": "68e4f79f886927de698df4f857de2aada41ccca6617e56bb0d61623b35b08cc0",
}
    </resp>

    <fields>
        <f name="value">The 256 bit value of the private key as hexadecimal string.</f>
    </fields>

    <h2>RequestAnnounce</h2>

    <desc>
        <p class=NemNoSpacing>A RequestAnnounce object is used
            to transfer the transaction data and the signature to NIS in order to initiate and
            broadcast a transaction.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{
        "data": "010100000100000000000000200000002b76078fa709bbe675
                 2222b215abc7ec0152ffe831fb4f9aed3e7749a425900a0009
                 3d0000000000000000002800000054444e46555946584f5353
                 334e4e4c4f35465a5348535a49354c33374b4e514945485055
                 4d584c54c0d45407000000000b00000001000000030000000c
                 3215",
        "signature": "db2473513c7f0ce9f8de6345f0fbe773
                      dc687eb571123d08eab4d98f96849eae
                      b63fa8756fb6c59d9b9d0e551537c1cd
                      ad4a564747ff9291db4a88b65c97c10d"
}
    </resp>

    <fields>
        <f name="data">The transaction data as string. The string is created by
            first creating the corresponding byte array (see chapter 6.7)
            and then converting the byte array to a hexadecimal string.
        </f>
        <f name="signature">The signature for the transaction as hexadecimal string.</f>
    </fields>

    <h2>RequestPrepareAnnounce</h2>

    <desc>
        <p class=NemNoSpacing>A RequestPrepareAnnounce object is used
            to transfer transaction data and a private key to NIS in order to initiate and
            broadcast a transaction.</p>
    </desc>

    <h4>JSON structure by example (test network):</h4>

    <resp>
{ 
       "transaction": 
       { 
              "timeStamp": 9111526, 
              "amount": 1000000000, 
              "fee": 3000000, 
              "recipient": "TDGIMREMR5NSRFUOMPI5OOHLDATCABNPC5ID2SVA", 
              "type": 257, 
              "deadline": 9154726, 
              "message": 
              { 
                     "payload": "74657374207472616e73616374696f6e", 
                     "type": 1 
              }, 
              "version": -1744830463,
              "signer": "a1aaca6c17a24252e674d155713cdf55996ad00175be4af02a20c67b59f9fe8a" 
       }, 
       "privateKey": "68e4f79f886927de698df4f857de2aada41ccca6617e56bb0d61623b35b08cc0"
}
    </resp>

    <fields>
        <f name="transaction">Denotes the beginning of the transaction data part. The
            transaction data is described in
            <appa>Transaction</appa>
            . The field 'signature is
            missing since the transaction is not signed at this point.
        </f>
        <f name="privateKey">The private key which NIS will use to sign the transaction.</f>
    </fields>
    <h2>TimeSynchronizationResult</h2>

    <desc>
        <p class=NemNoSpacing>A time synchronization result is the
            outcome of the network time synchronization of a node with other remote nodes.
            To agree upon a common time nodes need to synchronize time every hour.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{ 
       "dateTime": "2014-11-16 20:47:06", 
       "currentTimeOffset": 2786, 
       "change": 36 
} 
    </resp>

    <fields>
        <f name="dateTime">The date and time when the synchronization was performed.</f>
        <f name="currentTimeOffset">The current offset to the local computer clock in milliseconds.</f>
        <f name="change">The change in milliseconds compared to the last synchronization.</f>
    </fields>

    <h2>TransactionMetaData</h2>

    <desc>
        <p class=NemNoSpacing>Transactions meta data object contains
            additional information about the transaction.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{ 
       "height": 40706,
        "id": 2769,
        "hash": {
            "data":"37c34ead4c3fe6af42d994135798262f785ba2d807c02ac3608bc10da12e5f87"
        }
}
    </resp>

    <fields>
        <f name="height">The height of the block in which the transaction was included.</f>
        <f name="id">The id of the transaction.</f>
        <f name="hash">The transaction hash.</f>
    </fields>

    <h2>TransactionMetaDataPair</h2>

    <desc>
        <p class=NemNoSpacing>Transactions meta data object contains
            additional information about the transaction.</p>
    </desc>

    <h4>JSON structure by example:</h4>

    <resp>
{ 
       "meta": 
              &lt;TransactionMetaData&gt;, 
       "transaction": 
              &lt;Transaction&gt; 
} 
    </resp>

    <fields>
        <f name="meta">Contains the transaction meta data object.</f>
        <f name="&lt;TransactionMetaData&gt;">The transaction meta data object as described in <a
                href="#transactionMetaData">TransactionMetaData</a>.
        </f>
        <f name="Transaction">Contains the transaction object.</f>
        <f name="&lt;Transaction&gt;">The transaction object as described in <a
                href="#transaction">Transaction</a>.
        </f>
    </fields>

    <h2>UnconfirmedTransactionMetaData</h2>
    <desc>The unconfirmed transaction meta data contains the hash of the inner transaction in case the transaction is a multisig transaction. This data is need
        to initiate a multisig signature transaction.
    </desc>
    <resp>
{
    data": "d7c9e33421e43bf4a5d6e21304c8096c599142755d581bd6e9037f41545a5873"
}
    </resp>
    <fields>
        <f name="data">The hash of the inner transaction or null if the transaction is not a multisig transaction.</f>
    </fields>

    <h2>UnconfirmedTransactionMetaDataPair</h2>
    <desc>Transactions meta data object contains additional information about the transaction.</desc>
    <resp>
{
    "meta":
        &lt;UnconfirmedTransactionMetaData&gt;,
    "transaction":
        &lt;Transaction&gt;
}
    </resp>
    <fields>
        <f name="meta"> Contains the transaction meta data object.</f>
        <f name="&lt;UnconfirmedTransactionMetaData&gt;"> The transaction meta data object as described in UnconfirmedTransactionMetaData.</f>
        <f name="transaction"> Contains the transaction object.</f>
        <f name="&lt;Transaction&gt;"> The transaction object as described in Transaction.</f>
    </fields>


    <h2>Error object</h2>

    <desc>
        <p class=NemNoSpacing>If NIS encounters an error due to either
            invalid requests or internal problems, it returns a JSON error object. The
            interpretation of the error object is dependant on the context. See
            <alnk>Appendix B: NIS Errors</alnk>
            for detailed information about possible errors.
        </p>
    </desc>

    <h4>JSON structure by example</h4>

    <resp>
{ 
       "timeStamp": 9108808, 
       "error": "Bad Request", 
       "message": "address must be valid", 
       "status": 400 
} 
    </resp>

    <fields>
        <f name="timeStamp">The number of seconds elapsed since the creation of the nemesis block.</f>
        <f name="error">The general description of the error.</f>
        <f name="message">The detailed error message.</f>
        <f name="Status">The HTTP status.</f>
    </fields>

    <h1>Appendix B: NIS Errors</h1>

    <p>In case NIS encounters an error while
        processing a request it returns a JSON error object whose structure is
        described in
        <appa>Error object</appa>
        . This chapter describes the
        errors messages that can be returned from NIS.
    </p>

    <h2>Error messages</h2>

    <dl>
        <dt>Request method 'GET' not supported</dt>
        <dd>The request was performed as GET request but was expected to be a POST request.</dd>

        <dt>address must be valid:</dt>
        <dd>At least one address supplied in the request was invalid. Addresses are validated before processing a request. If validation fails, an error
            containing this message is returned.
        </dd>

        <dt>FAILURE_SERVER_LIMIT:</dt>
        <dd>The number of accounts that are allowed to harvest on NIS was exceeded.</dd>

        <dt>JSON Object was expected:</dt>
        <dd>A parameter is missing in the request.</dd>

        <dt>FAILURE_UNKNOWN_ACCOUNT:</dt>
        <dd>The account specified in the request is not known.</dd>

        <dt>block not found in the db</dt>
        <dd>The block that was requested could not be found in the database.</dd>

        <dt>height must be positive</dt>
        <dd>The block height supplied in a request was zero or negative. Block height must always be greater than zero.</dd>

        <dt>network has not been booted yet</dt>
        <dd>Most requests need the node that should answer the request to be already booted. If node is not booted yet, this error message will be returned.
        </dd>

        <dt>network boot was already attempted</dt>
        <dd>It was attempted to boot an already booted node. Nodes can only be booted once.</dd>

        <dt>remote 123.45.67.89 attempted to call local /node/boot</dt>
        <dd>It was attempted to boot a remote node. Only local node can be booted.</dd>

        <dt>FAILURE_PAST_DEADLINE</dt>
        <dd>The deadline for the entity has already expired. The deadline must always lie in the future.</dd>

        <dt>FAILURE_FUTURE_DEADLINE</dt>
        <dd>The deadline lies too far in the future. Deadlines are only allowed to lie up to 24 hours in the future.</dd>

        <dt>FAILURE_INSUFFICIENT_BALANCE</dt>
        <dd>The account does not have enough funds.</dd>

        <dt>FAILURE_MESSAGE_TOO_LARGE</dt>
        <dd>The message for the transaction exceeds the limit of 512 bytes.</dd>

        <dt>FAILURE_HASH_EXISTS</dt>
        <dd>The hash of the entity already exists either in the cache or in the database.</dd>

        <dt>FAILURE_SIGNATURE_NOT_VERIFIABLE</dt>
        <dd>The signature of the entity failed upon verification.</dd>

        <dt>FAILURE_TIMESTAMP_TOO_FAR_IN_PAST</dt>
        <dd>The timestamp of the entity lies to far in the past.</dd>

        <dt>FAILURE_TIMESTAMP_TOO_FAR_IN_FUTURE</dt>
        <dd>The timestamp of the entity lies too far in the future.</dd>

        <dt>FAILURE_INELIGIBLE_BLOCK_SIGNER</dt>
        <dd>Validation failed because the block had an ineligible signer. This usually occurs when remote harvesting is in the process of being activated or
            deactivated.
        </dd>

        <dt>FAILURE_ENTITY_UNUSABLE_OUT_OF_SYNC</dt>
        <dd>The entity cannot be processed because the remote node is out of synchronization with the local node. This happens frequently when a node is not
            fully synchronized and receives a new block with much larger height than its own chain.
        </dd>

        <dt>FAILURE_INSUFFICIENT_FEE</dt>
        <dd>The supplied transaction has an insufficient fee.</dd>

        <dt>FAILURE_NEMESIS_ACCOUNT_TRANSACTION_AFTER_NEMESIS_BLOCK</dt>
        <dd>The supplied transaction has the nemesis account as sender and cannot be included in a normal block.</dd>

        <dt>FAILURE_TRANSACTION_CACHE_TOO_FULL</dt>
        <dd>The transaction was rejected because the transaction cache is too full. This happens when an account tries to send too many transactions in a short
            time. To improve the chance that the transaction gets accepted you can try to raise the transaction fee.
        </dd>

        <dt>FAILURE_WRONG_NETWORK</dt>
        <dd>Entity was rejected because it has the wrong network specified.</dd>

        <dt>FAILURE_CANNOT_HARVEST_FROM_BLOCKED_ACCOUNT</dt>
        <dd>Block was rejected because it was harvested by a blocked account (typically a reserved NEM fund).</dd>

        <dt>FAILURE_DESTINATION_ACCOUNT_HAS_NONZERO_BALANCE</dt>
        <dd>The importance cannot be transferred to an account with nonzero balance.</dd>

        <dt>FAILURE_IMPORTANCE_TRANSFER_IN_PROGRESS</dt>
        <dd>The transaction is conflicting because there is already a transfer of importance in progress.</dd>

        <dt>FAILURE_IMPORTANCE_TRANSFER_NEEDS_TO_BE_DEACTIVATED</dt>
        <dd>The transaction is conflicting because the importance was already transferred.</dd>

        <dt>FAILURE_IMPORTANCE_TRANSFER_IS_NOT_ACTIVE</dt>
        <dd>The transaction is conflicting because no importance has been transferred yet.</dd>

        <dt>FAILURE_TRANSACTION_NOT_ALLOWED_FOR_REMOTE</dt>
        <dd>Validation failed because transaction is using remote account in an improper way.</dd>

        <dt>FAILURE_MULTISIG_NOT_A_COSIGNER</dt>
        <dd>The multisig transaction was rejected because the signer of the transaction is not a cosignatory of the sender account of the inner transaction.
        </dd>

        <dt>FAILURE_MULTISIG_INVALID_COSIGNERS</dt>
        <dd>Validation failed because the cosignatories attached to a multisig transaction were invalid.</dd>

        <dt>FAILURE_MULTISIG_NO_MATCHING_MULTISIG</dt>
        <dd>The signature transaction was rejected because the corresponding multisig transaction was not found.</dd>

        <dt>FAILURE_TRANSACTION_NOT_ALLOWED_FOR_MULTISIG</dt>
        <dd>The transaction was rejected because the signer is a multisig account. Multisig accounts are not allowed to initiate any transaction (only
            cosignatories are allowed to do so).
        </dd>

        <dt>FAILURE_MULTISIG_ALREADY_A_COSIGNER</dt>
        <dd>The transaction was rejected because it tried to add a cosignatory to a multisig account which already has this cosignatory.</dd>

        <dt>FAILURE_MULTISIG_MODIFICATION_MULTIPLE_DELETES</dt>
        <dd>The transaction was rejected because it tried to remove multiple cosignatories at once. It is only allowed to remove one cosignatory at a time.</dd>

        <dt>FAILURE_MULTISIG_MODIFICATION_REDUNDANT_MODIFICATIONS</dt>
        <dd>The transaction was rejected because it tried to do redundant modifications. This can happen if a transaction tries to add the same cosignatory two
            time.
        </dd>

        <dt>FAILURE_CONFLICTING_MULTISIG_MODIFICATION</dt>
        <dd>The transaction was rejected because it contained conflicting modifications to a multisig account. This can for instance happen if a transaction
            tries to add and then delete the same cosignatory.
        </dd>

        <dt>FAILURE_TOO_MANY_MULTISIG_COSIGNERS</dt>
        <dd>The transaction was rejected because it contains too many cosignatories. The maximum number of cosignatories allowed for a multisig account is 32.
        </dd>

        <dt>FAILURE_MULTISIG_ACCOUNT_CANNOT_BE_COSIGNER</dt>
        <dd>Validation failed because a multisig modification would result in a multisig account being a cosigner.</dd>

        <dt>FAILURE_MULTISIG_MIN_COSIGNATORIES_OUT_OF_RANGE</dt>
        <dd>Validation failed because the minimum number of cosignatories is negative or larger than the number of cosignatories.</dd>

        <dt>FAILURE_NAMESPACE_UNKNOWN</dt>
        <dd>Validation failed because the namespace is unknown.</dd>

        <dt>FAILURE_NAMESPACE_ALREADY_EXISTS</dt>
        <dd>Validation failed because the namespace already exists.</dd>

        <dt>FAILURE_NAMESPACE_EXPIRED</dt>
        <dd>Validation failed because the namespace has expired.</dd>

        <dt>FAILURE_NAMESPACE_OWNER_CONFLICT</dt>
        <dd>Validation failed because the transaction signer is not the owner of the namespace.</dd>

        <dt>FAILURE_NAMESPACE_INVALID_NAME(</dt>
        <dd>Validation failed because the name for the namespace is invalid.</dd>

        <dt>FAILURE_NAMESPACE_INVALID_RENTAL_FEE_SINK</dt>
        <dd>Validation failed because the specified namespace rental fee sink is invalid.</dd>

        <dt>FAILURE_NAMESPACE_INVALID_RENTAL_FEE</dt>
        <dd>Validation failed because the specified rental fee is invalid.</dd>

        <dt>FAILURE_NAMESPACE_PROVISION_TOO_EARLY</dt>
        <dd>Validation failed because the provision was done too early.</dd>

        <dt>FAILURE_NAMESPACE_NOT_CLAIMABLE</dt>
        <dd>Validation failed because the namespace contains a reserved part and is not claimable.</dd>

        <dt>FAILURE_MOSAIC_UNKNOWN</dt>
        <dd>Validation failed because the mosaic is unknown.</dd>

        <dt>FAILURE_MOSAIC_MODIFICATION_NOT_ALLOWED</dt>
        <dd>Validation failed because the modification of the existing mosaic is not allowed.</dd>

        <dt>FAILURE_MOSAIC_CREATOR_CONFLICT</dt>
        <dd>Validation failed because the transaction signer is not the creator of the mosaic.</dd>

        <dt>FAILURE_MOSAIC_SUPPLY_IMMUTABLE</dt>
        <dd>Validation failed because the mosaic supply is immutable.</dd>

        <dt>FAILURE_MOSAIC_MAX_SUPPLY_EXCEEDED</dt>
        <dd>Validation failed because the maximum overall mosaic supply is exceeded.</dd>

        <dt>FAILURE_MOSAIC_SUPPLY_NEGATIVE</dt>
        <dd>Validation failed because the resulting mosaic supply would be negative.</dd>

        <dt>FAILURE_MOSAIC_NOT_TRANSFERABLE</dt>
        <dd>Validation failed because the mosaic is not transferable.</dd>

        <dt>FAILURE_MOSAIC_DIVISIBILITY_VIOLATED</dt>
        <dd>Validation failed because the divisibility of the mosaic is violated.</dd>

        <dt>FAILURE_CONFLICTING_MOSAIC_CREATION</dt>
        <dd>Validation failed because conflicting mosaic creation is present.</dd>

        <dt>FAILURE_MOSAIC_INVALID_CREATION_FEE_SINK</dt>
        <dd>Validation failed because the mosaic creation fee sink is invalid.</dd>

        <dt>FAILURE_MOSAIC_INVALID_CREATION_FEE</dt>
        <dd>Validation failed because the specified creation fee is invalid.</dd>

        <dt>FAILURE_TOO_MANY_MOSAIC_TRANSFERS</dt>
        <dd>Validation failed because a transfer transaction had too many attached mosaic transfers.</dd>
    </dl>

</div>

</body>

</html>
